AnsibleでEC2インスタンスを作成してみようと思います。
インスタンスを作成してみます。
$ ansible-playbook -i ansible_hosts instance_create.yml
playbookは以下のようにしています。
インベントリファイルは以下のようなかんじ。
$ cat ansible_hosts [local] localhost
インスタンスが作成できました！
インスタンスを作成するところから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 -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"
}
Auto Scalingを利用していて、スケールインしたときの動きについてまとめてみます。
AWSドキュメントによると、スケールイン時のうごきが以下の通り。
Auto Scaling は、選択したアベイラビリティーゾーンで、保護されていないどのインスタンスが最も古い起動設定を使用しているかを判断します。このよう title:なインスタンスが 1 つある場合、そのインスタンスを終了します。
つまり、古いものから停止されていくので、グループ内で稼働し続けるようなインスタンスは存在しないということになります。
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してすべて取得してみたいと思います。
以下のようなテーブルを用意しています。
これをすべてscanして取得します。
コードは以下の通りです。単純ですね！
以下のような結果が返ってくるはずです。 (見やすいように整形済み)
{
'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した際の負荷がかなり高くなると思います。
そこらへんは要検討です。
PackerでWindowsServerのAMIをつくってみます。 これが考えられる最小構成だと思います。 これに肉付けすることでカスタムAMIを作成することができると思います。
Packerを利用してWindowsServer 2016のAMIを作成します。
もととなるAMIとして使ったのはAWSが提供しているMicrosoft Windows Server 2016 Baseです。
うごきとしては以下のような感じです。
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を実行しようとしたところ、以下のようなエラーが出てしまいました。
$ 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が実行できました。
Packerを利用してすこしカスタマイズしたAMIを作成してみたいと思います。
JSON形式で記載した設定ファイルのとおりにマシンイメージ(AWSであればAMI)を管理、作成することができるツールです。
たとえば、なにか共通の設定を入れたAMIをみんなで利用しているんですが、この共通のAMIってなんの設定がされているんだっけ？というのはよくある話かと思います。
そんなときに、Packerを利用して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"
]
}
]
}
amazon-ebsを指定します設定ファイルを作成したら、正しい形式かどうか確認します。
ただしければTemplate validated successfullyと表示されるはずです。間違っていた場合、その箇所が表示されるので設定ファイルを直しましょう。
$ packer validate ./template.json Template validated successfully.
いよいよ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 CEEDに接続する方法をご紹介します。
pi-top SPEAKERを箱から取り出します。
以下の端子にさしこみます。
さしこみました。
基本的にはこれでもう音が出るようになっているはずです。
わたしは差し込んだだけでは音がでませんでした。
そこでやったことをまとめます。(なにがきっかけで音が出るようになったかはわからないので超ご参考までに…)
まず、OSの更新を行いました。
$ sudo apt update $ sudo apt upgrade
pt-speakerをインストールする。基本的にはすでにインストールされているはずですがもう一度実行しました。
$ sudo apt install pt-speaker
auto-removeで不要なものを削除する$ sudo apt-get autoremove
これでpi-top SPEAKERから音が出るようになりました。
参考にしたページ↓
音質としては正直いいものではないです。
ブツッっというノイズがはいることもあります。
ですがpi-topで音を出したいとなったらこれをつかうのが一番良い方法じゃないかと思います。
pi-top CEED 日本仕様 (Raspberry なし, グリーン 緑色)
いまさらですがpi-top CEEDを買いましたので開封、組み立てていきます。
イギリスからものが届きました。
これをあけるとこんなかんじです。
いいかんじの箱があらわれました。
箱の裏面はこんなかんじ。
箱を開けてみると箱いっぱいに本体がはいっています。
かっちり正方形です。
本体をどけるとこんなかんじでパーツやマニュアルがはいっています。
さて、組み立てる前に内容物を確認していきます。
今回はRaspberryPi同梱のpi-topCEEDと、オプションでpi-topSPEAKERとpi-topPROTOというGPIO付きの基盤を購入しています。
まず、RaspberryPi本体です。
RaspberryPi 3 Model Bです。
箱の中で紙袋みたいなものに入っていてかっこいい！
続いて電源ケーブルです。
プラグの部分が取り外せるようになっています。
装着します。
ちなみに公式から購入した場合、プラグの形状を選ぶことができます。日本の場合はUStypeを選択すればOKです。
pi-top OSがインストール済みのmicroSDHCカードです。
SanDisk製のCLASS 10の8GBです。
SDカードアダプターは利用しないので捨てちゃってかまわないです(たぶん)
RaspberryPiのCPUに取り付けるヒートシンクです。
シール式でペタッと貼り付けるだけのタイプのやつです。
RaspberryPiのGPIOの各端子を示したカードです。
twitter idもかいてあります。
マニュアルです。
英語です。
pi-top専用のスピーカーです。
本体とは別に購入する必要があります。
pi-top CEED単体では音が出ません。
音とか必要ないよ。という場合には購入しなくてもいいと思います。
$19.99でした。
はこを開けるとこんなかんじでスピーカーがはいっています。
かわいい。
GPIO月の基盤です。
電子工作とかで遊びたい場合に大活躍するはずです。
$6.99です。
はこを開けるとこんなかんじで基盤とそれをとめるねじ類がはいっています。
さて、ここからは実際に本体を組み立てていきたいと思います。
SDカードアダプターからmicroSDカードを取り出し、RaspberryPi裏面に挿入します。
RaspberryPiの裏面の4つの穴に写真のように磁石付きのネジをはめます。
pi-top CEEDの下の蓋を開けます。
手でスライドするだけでひらくことができます。
ひらきました。
pi-top CEEDから出ているHDMIケーブルをRaspberryPiの端子に接続します。
(画像ではRaspberryPiにGPIOカードを装着していますが気にしなくていいです。)
Raspberry Piをスライドさせて、pi-top CEEDの横に設置します。
端子類が外から見えるようにします。
pi-top CEEDのGPIOケーブルをRaspberryPiに接続します。
わすれていました。
RaspberryPiにヒートシンクを装着します。
このタイミングである必要はないです。
RaspberryPiのCPUにペタッとはりつけます。
ふたをしめます。
本体横に電源ケーブルをさし、ボタンをいれます。
ボタンはすこしかたいので、強く長めにおすとよいです。
電源がつきました！
これでpi-top CEEDの組み立ては完了です！！！
おもいのほか質感がしっかりしていてけっこうかっこいいガジェットだと思います。
我が家ではこんなかんじにおいてあります。
液晶画面はノングレアです。
画面の角度の調整も
こんくらいから
こんくらいまでいけます
OSに関しては1,2時間さわっただけですが、特にRaspbianとの差異のようなものは感じていないです。
ちなみにRaspbianをインストールしてつかっても何も問題ないようです。
pi-topの公式から購入しまして値段はいかのような感じでした。
合計: 26,032円
($1 = \109.52で計算)
このくらいのお値段です。お手頃かそうでないかはわからない。
個人的にはRaspberryPiへの入門や、安価なLinuxマシンがほしいといった場合には買いだと思います。
↓公式 pi-top.com
日本国内では以下などで購入することができます。
以下はRaspberryPiが含まれていないので公式から買うよりも少し割高にはなってしまいますが、RaspberryPiをすでに持っていたり、送料のことなど考えると同じくらいのコストで手に入れることが可能かと思います。
pi-top CEED 日本仕様 (Raspberry なし, グリーン 緑色)
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
Amazon LinuxにPackerをインストールしてみたいと思います。
以下の環境で実施
まずwgetでPackerをダウンロードします。
$ wget https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip
packer_1.1.3_linux_amd64.zipを解凍します。
$ unzip ./packer_1.1.3_linux_amd64.zip
解凍できました。
以下がPacker本体です。
PATHが通っているところに格納しておきます。
$ sudo mv ./packer /usr/local/bin/.
以上でインストール完了です。
ためしに実行してみると以下のようなかんじです。
$ packer
Usage: packer [--version] [--help] <command> [<args>]
Available commands are:
build build image(s) from template
fix fixes templates from old versions of packer
inspect see components of a template
push push a template and supporting files to a Packer build service
validate check that a template is valid
version Prints the Packer version
Packerのくわしい使いかたなどはまた別にご紹介します。
それではまた
Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)
AnsibleでEC2 External Inventoryを試そうとしていたところ、以下のようなエラーがでてしまいました。
$ ./ec2.py ERROR: "Forbidden", while: getting ElastiCache clusters
ec2.iniのElastiCacheを無効にしたらうまくいきました。
以下のところ
# To exclude ElastiCache instances from the inventory, uncomment and set to False. elasticache = False
ひかくするとこんなかんじ
$ diff ec2.ini ec2.ini_changed 73c73 < #elasticache = False --- > elasticache = False
実行するとこんなかんじ
$ ./ec2.py
{
"_meta": {
"hostvars": {
"xxx.xxx.xxx.xxx: {
"ansible_host": "xxx.xxx.xxx.xxx",
"ec2__in_monitoring_element": false,
~~~省略~~~
ElastiCache以外にも利用していないAWSのサービスはFalseにして無効にしたほうがよさそうです。
他にもrds = Falseにしたほうがいい
などあるみたいです。
↓参考URL www.queryxchange.com
Ansibleを利用した構成管理では、実行対象のホストをインベントリファイルと呼ばれるファイルに記載しておく必要があります。
以下のようなかんじ
[local] localhosts [test_server] 192.140.1.1 192.140.1.2 [web_server] 192.140.2.1
これだと、AWSでAutoScalingを利用した際や、新たにインスタンスをたてたときなどにこのインベントリファイルをメンテナンスし続けなければならなくなり、非常に面倒です。
これを解決するために、Ansible公式でEC2 External Inventoryというスクリプトが提供されています。
以下のec2.pyとec2.iniがそのEC2 External Inventoryで利用するスクリプトと設定ファイルです。
実際にEC2 External InventoryをEC2インスタンス上からためしてみます。
まず、Ansibleサーバ上にec2.pyとec2.iniをダウンロードします。
$ wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/ec2.py
$ wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/ec2.ini
つづいて、AnsibleがAWSの環境を見に行くことができるようにAWS_ACCESS_KEY_IDとAWS_SECRET_ACCESS_KEYを環境変数に設定します。
$ export AWS_ACCESS_KEY_ID='AKIA1234567890' $ export AWS_SECRET_ACCESS_KEY='secretkey1234567890'
AnsibleサーバもAWSで動いていて、インスタンスに適切にロールが適用されている場合はこの作業は必要ありません。
以上で事前準備は完了です！
ec2.pyを単体で動かすと、以下のような情報がかえってきました。
$ ./ec2.py
{
"_meta": {
"ap-northeast-1a": [
"172.140.1.1",
"172.140.1.2"
],
"tag_Name_kabegiwa_ansible_server": [
"172.140.1.1"
],
"tag_Name_kabegiwa_ansible_client": [
"172.140.1.2"
],
"type_t2_micro": [
"172.140.1.2"
],
"type_t2_large": [
"172.140.1.2"
],
"vpc_id_vpc_12345678": [
"172.140.1.1",
"172.140.1.2"
]
AZやリージョン、タグ名などでまとまった情報がJSON形式で応答されていることがわかります。
このひとつひとつがAnsibleでいうグループになります。
実際にAnsibleを実行してみます。
Ansibleの-iオプションでec2.pyをわたしてあげるだけです。
たとえば、Nameタグがkabegiwa_ansible_clientのものにpingを実行してみます。
$ ansible -i ec2.py tag_Name_kabegiwa_ansible_client -u ec2-user --private-key='./himitsukagi.pem' -m ping
172.140.1.2 | SUCCESS => {
"changed": false,
"ping": "pong"
}
無事実行できました！
このようにEC2 External Inventoryをつかうことで動的にAnsibleのインベントリファイルを作成することができます。
インフラのコード化と自動化がはかどりますね！！！
今回はAnsibleでgit cloneを実行する方法をご紹介します。
今回はテスト用に以下のリポジトリを利用してみます。
https://github.com/takakabe/blog_RaspberryPi
各ターゲットノードに以下のモジュールが必要です。
## 実行コマンド
$ ansible-playbook -i ansible_hosts git.yml
[test_server] 172.140.1.1
- name: git_test hosts: test_server tasks: - git: repo=https://github.com:takakabe/blog_RaspberryPi.git dest=/home/ec2-user/test_git
以下のように/home/ec2-user/test_gitがリモートリポジトリの内容と同期されたことがわかる
$ ls /home/ec2-user/test_git/ L_chika.sh dht11.py light_sensor_led.py photo.sh pre_set_resist.py python_Lchika.py rain_sencer.py script.coffee tactswitch.py tactswitch_camera.py tactswitch_pulldown_resitor.py tactswitch_shutdown.py toggle.py toggle.py2
Gitがターゲットノードにインストールされていない場合 以下のようなエラーとなります。
$ which git /usr/bin/which: no git in (/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/opt/aws/bin:/home/quick/.local/bin:/home/quick/bin)
$ ansible-playbook -i ansible_hosts git.yml
PLAY [download_tes] ***********************************************************************************************
TASK [Gathering Facts] ********************************************************************************************
ok: [172.140.1.1]
TASK [git] ********************************************************************************************************
fatal: [172.140.1.1]: FAILED! => {"changed": false, "failed": true, "msg": "Failed to find required executable git in paths: /usr/local/bin:/bin:/usr/bin:/opt/aws/bin:/sbin:/usr/sbin:/usr/local/sbin"}
to retry, use: --limit @/home/ec2-user/ansible/git.retry
PLAY RECAP ********************************************************************************************************
172140.1.1 : ok=1 changed=0 unreachable=0 failed=1
