オフライン環境でZabbixエージェントをインストールする

今回はオフライン環境のLinuxサーバにZabbixエージェントをインストールしてみます。

手順

なんらかの方法で以下からZabbixエージェントをインストールしてきます。
http://repo.zabbix.com/zabbix/3.0/rhel/7/x86_64/

なんらかの方法でZabbixエージェントをインストールしたいサーバへダウンロードしてきたファイルを転送します。
(今回はzabbix-agent-3.0.14-1.el7.x86_64.rpmを転送しています)

以下のコマンドを実行して、Zabbixエージェントをインストールします。

$ sudo yum install ./zabbix-agent-3.0.14-1.el7.x86_64.rpm

確認

無事インストールすることができました！

$ yum list installed | grep zabbix
zabbix-agent.x86_64                 3.0.14-1.el7                       installed

サーバ／インフラエンジニア養成読本 ログ収集〜可視化編 [現場主導のデータ分析環境を構築！] Software Design plus

コマンドでWindows Serverの起動時に自動ログオンするよう設定する

今回はWindows Serverを起動した際の自動ログオンを実現してみます。

事前準備

マイクロソフト公式からAutoLogonをダウンロードしてきます。
ダウンロードできたら任意の場所に解凍しておきます。

technet.microsoft.com

自動ログオンの設定をする

さて、実際に自動ログオンの設定をしてみます。
AutoLogonを解凍したフォルダに移動し、以下のコマンドを実行します。
(ドメインではない場合はローカルのコンピュータ名を指定してください)

autologon ユーザ名 ドメイン名 パスワード

これだけで完了です！
あとは再起動してあげれば自動でログオンすることが確認できるはずです。

Windows Server 2016 パーフェクトマスター (Perfect Master)

AnsibleでWindowsにAWS CLIをインストールする

今回はAnsibleでWindows環境にAWS CLIをインストールしてみたいと思います。

事前準備

AWS公式からAWS CLIのインストーラをダウンロードしてきます。

aws.amazon.com

以下の赤枠から32ビットまたは64ビットのものをダウンロードします。

Ansibleを実行する

さて、実際にAnsibleを実行してAWS CLIをインストールしてみます。

実行コマンド

$ ansible-playbook -i hosts/target-hosts install_AWSCLI.yml

playbookは以下のような感じです。

win_copyでインストーラをターゲットノード(AWS CLIをインストールしたいサーバ)にコピーしたあと、win_msiを利用してインストールしています。

おわりに

Ansibleを利用してAWS CLIをインストールすることができました。
msi形式のインストーラであればwin_msiでインストーラのPATHを指定してあげるだけでインストールを行うことができます！

便利ですね！

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

Windows環境でPythonをコマンドでサイレントインストールする

今回はWindows環境でPythonをコマンプロンプトなどを利用してサイレントインストールしてみたいと思います。

コマンド

以下のコマンドをコマンドプロンプトで実行することでPyhtonをインストールすることができます。

C:\\python-3.6.3.exe /quiet InstallAllUsers=1 PrependPath=1 Include_test=0

この例ではPythonのバージョン3.6.3で実施しています。
バージョンの部分は各自読み替えて実行してみてください。

おまけ: Ansibleを利用してPythonをインストールする

サイレントインストールのコマンドをそのままAnsibleのwin_commandに記載してあげればAnsibleを利用してPythonをインストールすることが可能です。

install_python_win.yml

Ansible実践ガイド 第2版

AnsibleでEC2インスタンスを作成してみる

AnsibleでEC2インスタンスを作成してみようと思います。

環境

• Ansible 2.4.2
• python 2.7

インスタンスを作成してみる

インスタンスを作成してみます。

実行コマンド

$ ansible-playbook -i ansible_hosts instance_create.yml

playbookは以下のようにしています。

Ansible

インベントリファイルは以下のようなかんじ。

$ cat ansible_hosts
[local]
localhost

実行確認

インスタンスが作成できました！

おわりに

インスタンスを作成するところからAnsibleで実行することができます。
構成管理がはかどりますね！！！

初めてのAnsible

Ansibleのホストパターンは正規表現も利用できる

知らなかったので備忘録的メモです。

Ansibleのホストパターンは正規表現でも利用できました。
例えば以下のように指定が可能です。
正規表現の前には~を忘れないであげてください。

$ ansible -i ansible_hosts "~(test|wawawa)_server" -m ping

このとき、インベントリとして利用しているansible_hostsがこのような内容のとき、test_serverとwawawa_serverにpingが実行されます。

[test_server]
192.140.1.1

[wawawa_server]
192.140.1.2

[sasasa]
192.140.2.1

test_serverとwawawa_serverにpingが実行されていることがわかります。

$ ansible -i ansible_hosts *_server -m ping 
192.140.1.1 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}
192.140.1.2 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

Ansible実践ガイド 第2版

Ansibleのホストパターンにはワイルドカードが利用できる

知らなかったので備忘録的メモです。

例えば、以下のように指定が可能です。

$ ansible -i ansible_hosts *_server -m ping

このとき、インベントリとして利用しているansible_hostsがこのような内容のとき、test_serverとwawawa_serverにpingが実行されます。

[test_server]
192.140.1.1

[wawawa_server]
192.140.1.2

[sasasa]
192.140.2.1

test_serverとwawawa_serverにpingが実行されていることがわかります。

$ ansible -i ansible_hosts *_server -m ping 
192.140.1.1 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}
192.140.1.2 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

?も利用できます。

$ ansible -i ansible_hosts ????_server -m ping 
192.140.1.1 | SUCCESS => {
    "changed": false, 
    "ping": "pong"
}

Ansible実践ガイド 第2版

Auto Scalingでスケールインしたときの動作まとめ

概要

Auto Scalingを利用していて、スケールインしたときの動きについてまとめてみます。
AWSドキュメントによると、スケールイン時のうごきが以下の通り。

Auto Scaling は、選択したアベイラビリティーゾーンで、保護されていないどのインスタンスが最も古い起動設定を使用しているかを判断します。このよう title:なインスタンスが 1 つある場合、そのインスタンスを終了します。

docs.aws.amazon.com

つまり、古いものから停止されていくので、グループ内で稼働し続けるようなインスタンスは存在しないということになります。

実際に試してみる

Auto Scalingを設定して、実際に動きを確認してみます。

Auto Scaling(スケジュールされたイベント) の設定

設定は以下ようなかんじで設定してみました。

名前	繰り返し	最小	最大
start	5,15,25,35,45,55 * * * *	4	4
stop	0,10,20,30,40,50 * * * *	3	3

startとstopがcronに従って実行され、startで4台にスケールアウト、stopで3台にスケールインするような動きになります。

これでしばらく放置してみます。

実行結果確認

ログを見て、本当に古いインスタンスから削除されているのかを確認します。 ログは以下の実行ログのとおりです。
例えば、直近("StartTime": "2018-02-01T08:10:56.120Z")で停止されたi-ddddddddddddddddを見てみます。

このインスタンスが作成されたのは"StartTime": "2018-01-29T07:35:52.259Z"です。 その時点でのAuto Scaling Groupのインスタンスの起動時刻をそれぞれ表すと以下になります。

インスタンスID	起動時刻
i-ggggggggggggggggg	2018-02-03T08:05:31.933Z
i-fffffffffffffffff	2018-02-03T07:55:38.692Z
i-eeeeeeeeeeeeeeeee	2018-02-03T07:45:45.317Z
i-dddddddddddddddd	2018-02-03T07:35:52.259Z

実際に古いものから削除されているようです！

実行ログ

$  aws autoscaling describe-scaling-activities --auto-scaling-group-name kabegiwa_scaling_group --query 'Activities[].{StartTime:StartTime,Descriprtion:Description}'

[
    {
        "Descriprtion": "Terminating EC2 instance: i-dddddddddddddddd", 
        "StartTime": "2018-02-03T08:10:56.120Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action stop", 
        "StartTime": "2018-02-03T08:10:26.252Z"
    }, 
    {
        "Descriprtion": "Launching a new EC2 instance: i-ggggggggggggggggg", 
        "StartTime": "2018-02-03T08:05:31.933Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action start", 
        "StartTime": "2018-02-03T08:05:00.074Z"
    }, 
    {
        "Descriprtion": "Terminating EC2 instance: i-ccccccccccccccccc", 
        "StartTime": "2018-02-03T08:00:33.408Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action stop", 
        "StartTime": "2018-02-03T08:00:03.635Z"
    }, 
    {
        "Descriprtion": "Launching a new EC2 instance: i-fffffffffffffffff", 
        "StartTime": "2018-02-03T07:55:38.692Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action start", 
        "StartTime": "2018-02-03T07:55:07.006Z"
    }, 
    {
        "Descriprtion": "Terminating EC2 instance: i-bbbbbbbbbbbbbbbbb", 
        "StartTime": "2018-02-03T07:50:40.344Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action stop", 
        "StartTime": "2018-02-03T07:50:10.562Z"
    }, 
    {
        "Descriprtion": "Launching a new EC2 instance: i-eeeeeeeeeeeeeeeee", 
        "StartTime": "2018-02-03T07:45:45.317Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action start", 
        "StartTime": "2018-02-03T07:45:13.995Z"
    }, 
    {
        "Descriprtion": "Terminating EC2 instance: i-aaaaaaaaaaaaaaaaa", 
        "StartTime": "2018-02-03T07:40:47.193Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action stop", 
        "StartTime": "2018-02-03T07:40:17.326Z"
    }, 
    {
        "Descriprtion": "Launching a new EC2 instance: i-dddddddddddddddd", 
        "StartTime": "2018-02-03T07:35:52.259Z"
    }, 
    {
        "Descriprtion": "Executing scheduled action start", 
        "StartTime": "2018-02-03T07:35:20.733Z"
    } 
 ]

おわりに

Auto Scalingでインスタンスを管理すれば、それだけで長期間稼働するインスタンスをなくすことができそうです。

Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)

boto3でDynamoDBのテーブルの内容をscanしてすべて取得してみる

boto3を利用してDynamoDBのテーブルの内容をscanしてすべて取得してみたいと思います。

前提

以下のようなテーブルを用意しています。
これをすべてscanして取得します。

コード

コードは以下の通りです。単純ですね！

python

　
以下のような結果が返ってくるはずです。 (見やすいように整形済み)

{
    'Items': [{
        'name': {
            'S': 'kenkokukinen_no_hi'
        },
        'date': {
            'S': '0211'
        }
    }, {
        'name': {
            'S': 'seijin_no_hi'
        },
        'date': {
            'S': '0108'
        }
    }, {
        'name': {
            'S': 'gantan'
        },
        'date': {
            'S': '0101'
        }
    }],
    'Count': 3,
    'ScannedCount': 3,
}

おわりに

DynamoDBのテーブルの内容をすべて取得することができました。
テーブルの内容を変数に入れて、その内容を参照しに行けばDynamoDBへのアクセスを減らすことができます。

ただし、DynamoDBのデータが多い場合は、scanした際の負荷がかなり高くなると思います。
そこらへんは要検討です。

RDB技術者のためのNoSQLガイド

PackerでWindowsServerのAMIを作成する

PackerでWindowsServerのAMIをつくってみます。 これが考えられる最小構成だと思います。 これに肉付けすることでカスタムAMIを作成することができると思います。

環境

• Packer v1.1.3
• Packerが動いているサーバ : Amazon Linux 2
• PackerがつくるWindowsServerのAMI : Microsoft Windows Server 2016 Base

概要

Packerを利用してWindowsServer 2016のAMIを作成します。
もととなるAMIとして使ったのはAWSが提供しているMicrosoft Windows Server 2016 Baseです。

うごきとしては以下のような感じです。

• PackerがWindows Server 2016 Baseのインスタンスを作成/起動
• WinRMで接続してEC2Launchを実行
• AMI作成
• インスタンス削除

WinRMで接続して～のところでいろいろやるように肉付けするとお好みのカスタムAMIを作成することができます。

実際にやってみる

実行コマンド

$ packer build ./template.json 

実行ログ

amazon-ebs output will be in this color.
==> amazon-ebs: Prevalidating AMI Name: kabegiwa-test-windows-server
    amazon-ebs: Found Image ID: ami-157fe573
==> amazon-ebs: Creating temporary keypair: packer_5a6ac1d4-c926-1c2c-fb7e-f0cf78d180cb
==> amazon-ebs: Creating temporary security group for this instance: packer_5a6ac1d8-b367-106b-ea1b-bd7f142b710a
==> amazon-ebs: Authorizing access to port 5985 from 0.0.0.0/0 in the temporary security group...
==> amazon-ebs: Launching a source AWS instance...
==> amazon-ebs: Adding tags to source instance
    amazon-ebs: Adding tag: "Name": "Packer Builder"
    amazon-ebs: Instance ID: i-02c873d6d7833d311
==> amazon-ebs: Waiting for instance (i-02c873d6d7833d311) to become ready...
==> amazon-ebs: Waiting for auto-generated password for instance...
    amazon-ebs: It is normal for this process to take up to 15 minutes,
    amazon-ebs: but it usually takes around 5. Please wait.
    amazon-ebs:  
    amazon-ebs: Password retrieved!
==> amazon-ebs: Waiting for WinRM to become available...
    amazon-ebs: WinRM connected.
    amazon-ebs: #< CLIXML
    amazon-ebs: <Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04"><Obj S="progress" RefId="0"><TN RefId="0"><T>System.Management.Automation.PSCustomObject</T><T>System.Object</T></TN><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="1"><TNRef RefId="0" /><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj></Objs>
==> amazon-ebs: Connected to WinRM!
==> amazon-ebs: Provisioning with Powershell...
==> amazon-ebs: Provisioning with powershell script: /tmp/packer-powershell-provisioner631511055
    amazon-ebs:
    amazon-ebs: TaskPath                                       TaskName                          State
    amazon-ebs: --------                                       --------                          -----
    amazon-ebs: \                                              Amazon Ec2 Launch - Instance I... Ready
==> amazon-ebs: Stopping the source instance...
    amazon-ebs: Stopping instance, attempt 1
==> amazon-ebs: Waiting for the instance to stop...
==> amazon-ebs: Creating the AMI: kabegiwa-test-windows-server
    amazon-ebs: AMI: ami-xxxxxxxx
==> amazon-ebs: Waiting for AMI to become ready...
==> amazon-ebs: Terminating the source AWS instance...
==> amazon-ebs: Cleaning up any extra volumes...
==> amazon-ebs: Deleting temporary security group...
==> amazon-ebs: Deleting temporary keypair...
Build 'amazon-ebs' finished.
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
ap-northeast-1: ami-xxxxxxxx
{/code}
** template.json
{code}
{
    "builders": [{
        "type": "amazon-ebs",
        "region": "ap-northeast-1",
        "source_ami": "ami-157fe573",
        "instance_type": "m4.medium",
        "ami_name": "kabegiwa-test-windows-server",
        "user_data_file": "{{template_dir}}/setup_winrm.txt",
        "communicator": "winrm",
        "winrm_username": "Administrator"
    }],
    "provisioners": [
        {
            "type": "powershell",
            "inline": [
                "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Scripts\\InitializeInstance.ps1 -Schedule",
                "C:\\ProgramData\\Amazon\\EC2-Windows\\Launch\\Scripts\\SysprepInstance.ps1 -NoShutdown"
            ]
        }
    ]
}
{/code}
** setup_winrm.txt
{code}
<powershell>
winrm quickconfig -q
winrm set winrm/config/winrs '@{MaxMemoryPerShellMB="300"}'
winrm set winrm/config '@{MaxTimeoutms="1800000"}'
winrm set winrm/config/service '@{AllowUnencrypted="true"}'
winrm set winrm/config/service/auth '@{Basic="true"}'
netsh advfirewall firewall add rule name="WinRM 5985" protocol=TCP dir=in localport=5985 action=allow
netsh advfirewall firewall add rule name="WinRM 5986" protocol=TCP dir=in localport=5986 action=allow
net stop winrm
sc config winrm start=auto
net start winrm
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope LocalMachine
</powershell>

結果確認

実行ログを見るとami-xxxxxxxxというAMIが作成されたことがわかります。 それをもとにインスタンスを作成します。

インスタンス作成

$ aws ec2 run-instances \
--image-id ami-xxxxxxxx \
--subnet-id subnet-yyyyyyyy \
--security-group-ids sg-12345678 sg-abcdefgh \
--count 1 \
--instance-type t2.micro \
--key-name himitsu-key  \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=kabegiwa-test}]'

インスタンス起動確認

$ aws ec2 describe-instances --instance-id i-abcdefghijklmnop --query 'Reservations[]
.Instances[].State.Name'
[
    "running"
]

おわりに

無事にWindows ServerのAMIを作成、インスタンスを起動することができました！

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

Amazon Linux 2でPacker を実行したところ/usr/share/cracklib/pw_dict.pwd: Permission deniedのエラーがでる

事象

Amazon Linux 2 でPackerを実行しようとしたところ、以下のようなエラーが出てしまいました。

$ packer
/usr/share/cracklib/pw_dict.pwd: Permission denied
/usr/share/cracklib/pw_dict: Permission denied

原因

どうやら以下のPackerを実行してしまっているらしい。

$ which packer
/usr/sbin/packer

これはなにかとおもったらどうやらパスワードチェックなどに利用されるcracklib-packerのシンボリックリンクみたいです。

$ ls -l /usr/sbin/packer
lrwxrwxrwx 1 root root 15 Jan 16 18:44 /usr/sbin/packer -> cracklib-packer

解決法

シンボリックリンクを消してしまいます。

$ sudo rm /usr/sbin/packer

$ packer -v
Packer v1.1.3

無事Packerが実行できました。

AWSによるサーバーレスアーキテクチャ

PackerでカスタマイズしたAMIを作成してみる

Packerを利用してすこしカスタマイズしたAMIを作成してみたいと思います。

そもそもPackerとは？

JSON形式で記載した設定ファイルのとおりにマシンイメージ(AWSであればAMI)を管理、作成することができるツールです。

たとえば、なにか共通の設定を入れたAMIをみんなで利用しているんですが、この共通のAMIってなんの設定がされているんだっけ？というのはよくある話かと思います。

そんなときに、Packerを利用してAMIを作成していれば、設定ファイルにAMIのカスタマイズした内容がはいっているため、AMIのブラックボックス化を避けることができ、管理運用が楽になります。

実際にAMIを作成してみる

Packerを利用してかんたんにAMIを作成してみたいと思います。

事前準備

アクセス権限の設定

PackerがAWSの環境をさわることができるようにAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYを環境変数に設定します。

$ export AWS_ACCESS_KEY_ID='AKIA1234567890'
$ export AWS_SECRET_ACCESS_KEY='secretkey1234567890'

PackerがAWSで動いていて、そのインスタンスに適切にロールが適用されている場合、この作業は必要ありません。

設定ファイルの作成

設定ファイルをつくっていきます。これに記載したとおりにAMIが作成できます。
今回は以下のような設定ファイルをtemplate.jsonという名前で作成してみます。

{
  "builders": [
    {
      "type": "amazon-ebs",
      "region": "ap-northeast-1",
      "source_ami": "ami-ceafcba8",
      "instance_type": "t2.micro",
      "ssh_username": "ec2-user",
      "ssh_timeout": "5m",
      "ami_name": "packer_kabegiwa_test"
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "inline": [
        "sudo yum -y install httpd"
      ]
    }
  ]
}

設定ファイルの説明

• type - AWSの場合はamazon-ebsを指定します
• region - AMIを作成するリージョン
• source_ami - もととなるAMI
• instance_type - 作成するAMIのインスタンスタイプ
• ssh_username - ssh接続するユーザ名
• ssh_timeout - PackerがAMIを作る際に作成するインスタンスにssh接続する際のタイムアウト時間です
• ami_name - 作成するAMIの名前

設定ファイルの確認

設定ファイルを作成したら、正しい形式かどうか確認します。
ただしければTemplate validated successfullyと表示されるはずです。間違っていた場合、その箇所が表示されるので設定ファイルを直しましょう。

$ packer validate ./template.json
Template validated successfully.

Packerの実行

いよいよPackerを実行してAMIを作成していきます。
Packerの動きは以下の実行結果でも出力されていますが、一度インスタンスを作成して、それを削除、AMIを作成する。といった動きになっています。
ですので完了まですこし時間がかかります。

$ packer build ./template.json
amazon-ebs output will be in this color.

==> amazon-ebs: Prevalidating AMI Name: packer_kabegiwa_test
    amazon-ebs: Found Image ID: ami-ceafcba8
==> amazon-ebs: Creating temporary keypair: packer_5a6a5427-6bee-f205-2dea-085dec632299
==> amazon-ebs: Creating temporary security group for this instance: packer_5a6a542c-0a83-6f35-1554-259238d5a694
==> amazon-ebs: Authorizing access to port 22 from 0.0.0.0/0 in the temporary security group...
==> amazon-ebs: Launching a source AWS instance...
==> amazon-ebs: Adding tags to source instance
    amazon-ebs: Adding tag: "Name": "Packer Builder"
    amazon-ebs: Instance ID: i-05085ea79700a8499
==> amazon-ebs: Waiting for instance (i-05085ea79700a8499) to become ready...
==> amazon-ebs: Waiting for SSH to become available...
==> amazon-ebs: Connected to SSH!
==> amazon-ebs: Provisioning with shell script: /tmp/packer-shell459550516
    amazon-ebs: Loaded plugins: priorities, update-motd, upgrade-helper
    amazon-ebs: Resolving Dependencies
    amazon-ebs: --> Running transaction check
    amazon-ebs: ---> Package httpd.x86_64 0:2.2.34-1.16.amzn1 will be installed
    amazon-ebs: --> Processing Dependency: httpd-tools = 2.2.34-1.16.amzn1 for package: httpd-2.2.34-1.16.amzn1.x86_64
    amazon-ebs: --> Processing Dependency: apr-util-ldap for package: httpd-2.2.34-1.16.amzn1.x86_64
    amazon-ebs: --> Processing Dependency: libaprutil-1.so.0()(64bit) for package: httpd-2.2.34-1.16.amzn1.x86_64
    amazon-ebs: --> Processing Dependency: libapr-1.so.0()(64bit) for package: httpd-2.2.34-1.16.amzn1.x86_64
    amazon-ebs: --> Running transaction check
    amazon-ebs: ---> Package apr.x86_64 0:1.5.2-5.13.amzn1 will be installed
    amazon-ebs: ---> Package apr-util.x86_64 0:1.5.4-6.18.amzn1 will be installed
    amazon-ebs: ---> Package apr-util-ldap.x86_64 0:1.5.4-6.18.amzn1 will be installed
    amazon-ebs: ---> Package httpd-tools.x86_64 0:2.2.34-1.16.amzn1 will be installed
    amazon-ebs: --> Finished Dependency Resolution
    amazon-ebs:
    amazon-ebs: Dependencies Resolved
    amazon-ebs:
    amazon-ebs: ================================================================================
    amazon-ebs:  Package            Arch        Version                 Repository         Size
    amazon-ebs: ================================================================================
    amazon-ebs: Installing:
    amazon-ebs:  httpd              x86_64      2.2.34-1.16.amzn1       amzn-updates      1.2 M
    amazon-ebs: Installing for dependencies:
    amazon-ebs:  apr                x86_64      1.5.2-5.13.amzn1        amzn-updates      118 k
    amazon-ebs:  apr-util           x86_64      1.5.4-6.18.amzn1        amzn-updates       99 k
    amazon-ebs:  apr-util-ldap      x86_64      1.5.4-6.18.amzn1        amzn-updates       19 k
    amazon-ebs:  httpd-tools        x86_64      2.2.34-1.16.amzn1       amzn-updates       80 k
    amazon-ebs:
    amazon-ebs: Transaction Summary
    amazon-ebs: ================================================================================
    amazon-ebs: Install  1 Package (+4 Dependent packages)
    amazon-ebs:
    amazon-ebs: Total download size: 1.5 M
    amazon-ebs: Installed size: 3.6 M
    amazon-ebs: Downloading packages:
    amazon-ebs: --------------------------------------------------------------------------------
    amazon-ebs: Total                                              653 kB/s | 1.5 MB  00:02
    amazon-ebs: Running transaction check
    amazon-ebs: Running transaction test
    amazon-ebs: Transaction test succeeded
    amazon-ebs: Running transaction
    amazon-ebs:   Installing : apr-1.5.2-5.13.amzn1.x86_64                                  1/5
    amazon-ebs:   Installing : apr-util-1.5.4-6.18.amzn1.x86_64                             2/5
    amazon-ebs:   Installing : httpd-tools-2.2.34-1.16.amzn1.x86_64                         3/5
    amazon-ebs:   Installing : apr-util-ldap-1.5.4-6.18.amzn1.x86_64                        4/5
    amazon-ebs:   Installing : httpd-2.2.34-1.16.amzn1.x86_64                               5/5
    amazon-ebs:   Verifying  : httpd-tools-2.2.34-1.16.amzn1.x86_64                         1/5
    amazon-ebs:   Verifying  : apr-util-1.5.4-6.18.amzn1.x86_64                             2/5
    amazon-ebs:   Verifying  : httpd-2.2.34-1.16.amzn1.x86_64                               3/5
    amazon-ebs:   Verifying  : apr-1.5.2-5.13.amzn1.x86_64                                  4/5
    amazon-ebs:   Verifying  : apr-util-ldap-1.5.4-6.18.amzn1.x86_64                        5/5
    amazon-ebs:
    amazon-ebs: Installed:
    amazon-ebs:   httpd.x86_64 0:2.2.34-1.16.amzn1
    amazon-ebs:
    amazon-ebs: Dependency Installed:
    amazon-ebs:   apr.x86_64 0:1.5.2-5.13.amzn1
    amazon-ebs:   apr-util.x86_64 0:1.5.4-6.18.amzn1
    amazon-ebs:   apr-util-ldap.x86_64 0:1.5.4-6.18.amzn1
    amazon-ebs:   httpd-tools.x86_64 0:2.2.34-1.16.amzn1
    amazon-ebs:
    amazon-ebs: Complete!
==> amazon-ebs: Stopping the source instance...
    amazon-ebs: Stopping instance, attempt 1
==> amazon-ebs: Waiting for the instance to stop...
==> amazon-ebs: Creating the AMI: packer_kabegiwa_test
    amazon-ebs: AMI: ami-daabc7bc
==> amazon-ebs: Waiting for AMI to become ready...
==> amazon-ebs: Terminating the source AWS instance...
==> amazon-ebs: Cleaning up any extra volumes...
==> amazon-ebs: No volumes to clean up, skipping
==> amazon-ebs: Deleting temporary security group...
==> amazon-ebs: Deleting temporary keypair...
Build 'amazon-ebs' finished.

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
ap-northeast-1: ami-daabc7bc

実行結果を確認してみる

以下のようにAMIが作成されていることがわかります。

このAMIからインスタンスを作成してみたところ、以下のようにhttpdがインストールさえれていることがわかります！

$ yum list installed | grep httpd
httpd.x86_64                         2.2.34-1.16.amzn1             @amzn-updates
httpd-tools.x86_64                   2.2.34-1.16.amzn1             @amzn-updates

おわりに

Packerを利用してAMIを作成することができました。

すこし面倒ですが、一度PackerをとおしてAMIを作成していれば、Packerの設定ファイルでこのAMIになにがインストールされているのか、どんな設定をしたのかがわかるようになります。

めんどうなドキュメント作成からすこし開放されるかもしれません。

DevOps導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する (DEV Engineer’s Books)

pi-top SPEAKER の接続とセットアップ方法

pi-top SPEAKERをpi-top CEEDに接続する方法をご紹介します。

環境

• pi-top OS
• pi-top CEED
• pi-top SPEAKER v2

接続方法

pi-top SPEAKERを箱から取り出します。

以下の端子にさしこみます。

さしこみました。

基本的にはこれでもう音が出るようになっているはずです。

音が出ない場合

わたしは差し込んだだけでは音がでませんでした。
そこでやったことをまとめます。(なにがきっかけで音が出るようになったかはわからないので超ご参考までに…)

pi-top OSを最新版にする

まず、OSの更新を行いました。

$ sudo apt update
$ sudo apt upgrade

pt-speakerをインストールする。

基本的にはすでにインストールされているはずですがもう一度実行しました。

$ sudo apt install pt-speaker

auto-removeで不要なものを削除する

$ sudo apt-get autoremove

これでpi-top SPEAKERから音が出るようになりました。

参考にしたページ↓

support.pi-top.com

おわりに

音質としては正直いいものではないです。
ブツッっというノイズがはいることもあります。
ですがpi-topで音を出したいとなったらこれをつかうのが一番良い方法じゃないかと思います。

pi-top CEED 日本仕様 (Raspberry なし, グリーン 緑色)

pi-top CEED 買ったので開封レビューと組み立て

いまさらですがpi-top CEEDを買いましたので開封、組み立てていきます。

開封してみる

イギリスからものが届きました。

これをあけるとこんなかんじです。
いいかんじの箱があらわれました。

箱の裏面はこんなかんじ。

箱を開けてみると箱いっぱいに本体がはいっています。
かっちり正方形です。

本体をどけるとこんなかんじでパーツやマニュアルがはいっています。

内容物を確認する

さて、組み立てる前に内容物を確認していきます。

今回はRaspberryPi同梱のpi-topCEEDと、オプションでpi-topSPEAKERとpi-topPROTOというGPIO付きの基盤を購入しています。

Raspberry Pi 本体

まず、RaspberryPi本体です。
RaspberryPi 3 Model Bです。

箱の中で紙袋みたいなものに入っていてかっこいい！

電源ケーブル

続いて電源ケーブルです。
プラグの部分が取り外せるようになっています。
装着します。

ちなみに公式から購入した場合、プラグの形状を選ぶことができます。日本の場合はUStypeを選択すればOKです。

microSDHCカード(pi-top OSインストール済み)

pi-top OSがインストール済みのmicroSDHCカードです。
SanDisk製のCLASS 10の8GBです。 SDカードアダプターは利用しないので捨てちゃってかまわないです(たぶん)

CPU ヒートシンク

RaspberryPiのCPUに取り付けるヒートシンクです。
シール式でペタッと貼り付けるだけのタイプのやつです。

GPIOカード

RaspberryPiのGPIOの各端子を示したカードです。
twitter idもかいてあります。

マニュアル

マニュアルです。
英語です。

pi-top SPEAKER(別売り)

pi-top専用のスピーカーです。
本体とは別に購入する必要があります。
pi-top CEED単体では音が出ません。
音とか必要ないよ。という場合には購入しなくてもいいと思います。
$19.99でした。
はこを開けるとこんなかんじでスピーカーがはいっています。
かわいい。

pi-top PRORO(別売り)

GPIO月の基盤です。
電子工作とかで遊びたい場合に大活躍するはずです。
$6.99です。

はこを開けるとこんなかんじで基盤とそれをとめるねじ類がはいっています。

本体を組み立てる

さて、ここからは実際に本体を組み立てていきたいと思います。

RaspberryPiにmicroSDカードを挿入する

SDカードアダプターからmicroSDカードを取り出し、RaspberryPi裏面に挿入します。

RaspberryPiに磁石付きのねじをはめる

RaspberryPiの裏面の4つの穴に写真のように磁石付きのネジをはめます。

pi-top CEED のふたを開ける

pi-top CEEDの下の蓋を開けます。
手でスライドするだけでひらくことができます。

ひらきました。

RaspberryPiにHDMIケーブルを接続する

pi-top CEEDから出ているHDMIケーブルをRaspberryPiの端子に接続します。
(画像ではRaspberryPiにGPIOカードを装着していますが気にしなくていいです。)

RaspberryPiを所定の位置に設置する

Raspberry Piをスライドさせて、pi-top CEEDの横に設置します。
端子類が外から見えるようにします。

GPIOケーブルを接続する

pi-top CEEDのGPIOケーブルをRaspberryPiに接続します。

RaspberryPiにヒートシンクをつける

わすれていました。
RaspberryPiにヒートシンクを装着します。
このタイミングである必要はないです。

RaspberryPiのCPUにペタッとはりつけます。

ふたをしめる

ふたをしめます。

電源ケーブルをさし、電源ボタンを押して電源をいれる

本体横に電源ケーブルをさし、ボタンをいれます。
ボタンはすこしかたいので、強く長めにおすとよいです。

電源がつきました！

これでpi-top CEEDの組み立ては完了です！！！

雑レビュー

全体的に

おもいのほか質感がしっかりしていてけっこうかっこいいガジェットだと思います。
我が家ではこんなかんじにおいてあります。

画面

液晶画面はノングレアです。

角度調整

画面の角度の調整も
こんくらいから

こんくらいまでいけます

pi-top OS

OSに関しては1,2時間さわっただけですが、特にRaspbianとの差異のようなものは感じていないです。
ちなみにRaspbianをインストールしてつかっても何も問題ないようです。

値段

pi-topの公式から購入しまして値段はいかのような感じでした。

• pi-top CEED(RaspberryPi入り) $149.99
• pi-top SPEAKER $19.99
• pi-top PROTO $6.99
• 送料 $39.89
• 消費税/関税手数料 \2280

合計: 26,032円
($1 = \109.52で計算)

このくらいのお値段です。お手頃かそうでないかはわからない。

個人的にはRaspberryPiへの入門や、安価なLinuxマシンがほしいといった場合には買いだと思います。

↓公式 pi-top.com

おわりに

日本国内では以下などで購入することができます。
以下はRaspberryPiが含まれていないので公式から買うよりも少し割高にはなってしまいますが、RaspberryPiをすでに持っていたり、送料のことなど考えると同じくらいのコストで手に入れることが可能かと思います。

pi-top CEED 日本仕様 (Raspberry なし, グリーン 緑色)

EC2 External InventoryでプライベートIPで取得したい

AnsibleのEC2 External InventoryでEC2インスタンスの情報を取得したとき、デフォルトのままだと以下のようにIPアドレスがパブリックIPで表示されるかと思います。

$ ./ec2.py 
{
"_meta": {
  "ap-northeast-1a": [
    "54.xxx.xxx.xxx", 
    "13.yyy.yyy.yyy"
  ], 
  "tag_Name_kabegiwa_ansible_server": [
    "54.xxx.xxx.xxx"
  ], 
  "tag_Name_kabegiwa_ansible_client": [
    "13.yyy.yyy.yyy"
  ]

そして、パブリックIPを設定していないインスタンスについては情報がとれていませんでした。

解決法

設定ファイルであるec2.iniのvpc_destination_variableをprivate_ip_addressに変更したところ、うまくいきました。

以下のように変更

vpc_destination_variable = private_ip_address
# vpc_destination_variable = ip_address

こんなかんじで無事に表示されるようになります。

$ ./ec2.py 
{
"_meta": {
  "ap-northeast-1a": [
    "172.140.1.1", 
    "172.140.1.2",
    "172.140.1.3"
  ], 
  "tag_Name_kabegiwa_ansible_server": [
    "172.140.1.1"
  ], 
  "tag_Name_kabegiwa_ansible_client": [
    "172.140.1.2"
  ],
  "tag_Name_kabegiwa_private": [
    "172.140.1.3"
  ]

おわりに

以下のように両方設定を残してしまうと下にある項目の設定になってしまうようです。(パブリックIPしか表示されないような状態になってしまう)

vpc_destination_variable = private_ip_address
vpc_destination_variable = ip_address

Ansible完全読本