かべぎわブログ

ブログです

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によるサーバーレスアーキテクチャ

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

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

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

そもそもPackerとは?

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

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

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

実際にAMIを作成してみる

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

事前準備

アクセス権限の設定

PackerがAWSの環境をさわることができるようにAWS_ACCESS_KEY_IDAWS_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が作成されていることがわかります。
f:id:kabegiwakun:20180127193501p:plain

この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)

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

  • 作者: 河村聖悟,北野太郎,中山貴尋,日下部貴章,株式会社リクルートテクノロジーズ
  • 出版社/メーカー: 翔泳社
  • 発売日: 2016/10/14
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

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

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

環境

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

接続方法

pi-top SPEAKERを箱から取り出します。 f:id:kabegiwakun:20180125073128j:plain

以下の端子にさしこみます。
f:id:kabegiwakun:20180125073228j:plain

さしこみました。
f:id:kabegiwakun:20180125073257j:plain
基本的にはこれでもう音が出るようになっているはずです。

音が出ない場合

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

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 日本仕様 (Raspberry なし, グリーン 緑色)

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

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

開封してみる

イギリスからものが届きました。
f:id:kabegiwakun:20180124202644j:plain

これをあけるとこんなかんじです。
いいかんじの箱があらわれました。
f:id:kabegiwakun:20180124202753j:plain

箱の裏面はこんなかんじ。
f:id:kabegiwakun:20180124202851j:plain

箱を開けてみると箱いっぱいに本体がはいっています。
かっちり正方形です。
f:id:kabegiwakun:20180124203322j:plain

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

内容物を確認する

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

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

Raspberry Pi 本体

まず、RaspberryPi本体です。
RaspberryPi 3 Model Bです。
f:id:kabegiwakun:20180124203751j:plain
箱の中で紙袋みたいなものに入っていてかっこいい!
f:id:kabegiwakun:20180124203842j:plain

電源ケーブル

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

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

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

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

CPU ヒートシンク

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

GPIOカード

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

マニュアル

マニュアルです。
英語です。
f:id:kabegiwakun:20180124205731j:plain

pi-top SPEAKER(別売り)

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

pi-top PRORO(別売り)

GPIO月の基盤です。
電子工作とかで遊びたい場合に大活躍するはずです。
$6.99です。
f:id:kabegiwakun:20180124210928j:plain
はこを開けるとこんなかんじで基盤とそれをとめるねじ類がはいっています。
f:id:kabegiwakun:20180124211012j:plain

本体を組み立てる

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

RaspberryPiにmicroSDカードを挿入する

SDカードアダプターからmicroSDカードを取り出し、RaspberryPi裏面に挿入します。
f:id:kabegiwakun:20180124211321j:plain

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

RaspberryPiの裏面の4つの穴に写真のように磁石付きのネジをはめます。
f:id:kabegiwakun:20180124211555j:plain

pi-top CEED のふたを開ける

pi-top CEEDの下の蓋を開けます。
手でスライドするだけでひらくことができます。
f:id:kabegiwakun:20180124211905j:plain
ひらきました。
f:id:kabegiwakun:20180124211924j:plain

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

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

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

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

GPIOケーブルを接続する

pi-top CEEDのGPIOケーブルをRaspberryPiに接続します。
f:id:kabegiwakun:20180124213126j:plain

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

わすれていました。
RaspberryPiにヒートシンクを装着します。
このタイミングである必要はないです。
f:id:kabegiwakun:20180124213327j:plain
RaspberryPiのCPUにペタッとはりつけます。
f:id:kabegiwakun:20180124213343j:plain

ふたをしめる

ふたをしめます。 f:id:kabegiwakun:20180124213211j:plain

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

本体横に電源ケーブルをさし、ボタンをいれます。
ボタンはすこしかたいので、強く長めにおすとよいです。
f:id:kabegiwakun:20180124213439j:plain
電源がつきました!
f:id:kabegiwakun:20180124213604j:plain
これでpi-top CEEDの組み立ては完了です!!!

雑レビュー

全体的に

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

画面

液晶画面はノングレアです。
f:id:kabegiwakun:20180124214326j:plain

角度調整

画面の角度の調整も
こんくらいから
f:id:kabegiwakun:20180124214428j:plain
こんくらいまでいけます
f:id:kabegiwakun:20180124214456j:plain

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 なし, グリーン 緑色)

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_variableprivate_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完全読本

Ansible完全読本

Amazon LinuxにPackerをインストールする

Amazon LinuxにPackerをインストールしてみたいと思います。

環境

以下の環境で実施

  • Amazon Linux AMI 2017.09.1 (HVM), SSD Volume Type (ami-ceafcba8)
  • Packer 1.1.3 linux 64bit

インストール手順

Packerのダウンロード

まずwgetでPackerをダウンロードします。

$ wget https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip

ダウンロードしてきた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)

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

  • 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2018/01/20
  • メディア: 単行本
  • この商品を含むブログを見る

AnsibleのEC2 External Inventory で ERROR: "Forbidden", while: getting ElastiCache clusters エラーの解決法

事象

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実践ガイド

Ansible実践ガイド

EC2 External Inventoryを利用してAnsibleのhostsを動的に管理する

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.pyec2.iniがそのEC2 External Inventoryで利用するスクリプトと設定ファイルです。

github.com

実際に動かしてためしてみる

実際にEC2 External InventoryをEC2インスタンス上からためしてみます。

事前準備

ファイルのダウンロード

まず、Ansibleサーバ上にec2.pyec2.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_IDAWS_SECRET_ACCESS_KEYを環境変数に設定します。

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

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

以上で事前準備は完了です!

ためしにec2.pyを動かしてみる

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を実行してみます。
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

入門Ansible

Ansibleでgit cloneを実行する

今回はAnsibleでgit cloneを実行する方法をご紹介します。 今回はテスト用に以下のリポジトリを利用してみます。

https://github.com/takakabe/blog_RaspberryPi

前提条件

各ターゲットノードに以下のモジュールが必要です。

  • git>=1.7.1 (the command line tool)

## 実行コマンド

$ ansible-playbook -i ansible_hosts git.yml

ansible_hosts

[test_server]
172.140.1.1

git.yml

- 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   

Ansible徹底入門 クラウド時代の新しい構成管理の実現

Ansible徹底入門 クラウド時代の新しい構成管理の実現

  • 作者: 廣川英寿,平初,橋本直哉,森田邦裕,渡辺一宏
  • 出版社/メーカー: 翔泳社
  • 発売日: 2017/02/17
  • メディア: 単行本(ソフトカバー)
  • この商品を含むブログを見る

AnsibleでS3からファイルをダウンロードする3つの方法

AnsibleでS3からファイルをダウンロードする方法を紹介します!

① s3_getを利用する

AnsibleのCloudModuleであるs3_getを利用する方法です。

前提条件

  • ターゲットノードにS3へのアクセス許可が必要

実行コマンド

$ ansible-playbook -i ansible_hosts s3_get.yml

ansible_hosts

[test_server]
172.140.1.1

s3_get.yml

- name: s3_get
  hosts: test_server
  tasks:
   - aws_s3:
       bucket: kabegiwa-bucket
       object: /test.txt
       dest: /home/ec2-user/test.txt
       mode: get

② get_urlを利用する

S3バケットに静的Webサイトホスティングの設定またはオブジェクトごとにPublicアクセスの許可設定を実施し、ダウンロードを行う方法です。

前提条件

  • S3上のファイルは静的WebホスティングまたはPublicアクセスの許可が必要

    実行コマンド

$ ansible-playbook -i ansible_hosts geturl.yml

ansible_hosts

[test_server]
172.140.1.1

geturl.yml

- name: get_url_test
  hosts: test_server
  tasks:
    - get_url: url=https://s3-ap-northeast-1.amazonaws.com/kabegiwa-bucket/test.txt dest=/home/ec2-user/

③ AWSCLIを利用する方法

単純にAnsibleのcommandを利用してAWSCLIを実行させます。

前提条件

  • ターゲットノードにS3へのアクセス許可がなければならない
  • ターゲットノードにAWSCLIがインストールされていなければならない

    実行コマンド

$ ansible-playbook -i ansible_hosts awscli.yml

ansible_hosts

[linux]
172.22.69.51

awscli.yml

- name: awscli_test
  hosts: test_server
  tasks:
    - command: 'aws s3 cp s3://kabegiwa-bucket/test.txt /home/ec2-user/test.txt'

入門Ansible

入門Ansible

Ansibleでboto3 and botocore required for this moduleというエラーがでたときの対処法

事象

AnsibleでS3を操作しようとしていたところ、以下のようなエラーが出てしまいました。

PLAY [s3_get] *****************************************************************************************************

TASK [Gathering Facts] ********************************************************************************************
ok: [172.140.1.1]

TASK [aws_s3] *****************************************************************************************************
fatal: [172.140.1.1]: FAILED! => {"changed": false, "failed": true, "msg": "boto3 and botocore required for this module"}
        to retry, use: --limit @/home/ec2-user/ansible/s3_get.retry

PLAY RECAP ********************************************************************************************************
172.140.1.1               : ok=1    changed=0    unreachable=0    failed=1   

boto3とbotocoreが必要だよ!と言われているのだが、以下のように両方ちゃんとはいっているはず…

$ pip freeze | grep boto
boto==2.48.0
boto3==1.5.18
botocore==1.8.32
$ python --version
Python 2.7.12

解決策

ansible_hostsにansible_python_interpreterの定義を追加してあげたところうまくいきました!

172.140.1.1 ansible_python_interpreter=/usr/bin/python

PythonのPATHを明示して記載してあげています。
どうやらAnsibleがPythonを探せていなかったようです。

初めてのAnsible

初めてのAnsible

AnsibleからWindowsServerへファイルをコピーする方法

Ansibleを利用してWindowsServerへファイルをコピーする方法をご紹介します。

設定手順

AnsibleからWindowsを操作するためにはWindows側とAnsible側の両方にすこし準備が必要です。
AnsibleはターゲットのサーバにWindows Remote Manager(WinRM)を利用してアクセスを行いますので、それを有効にする必要があります。

WindowsServerの設定

PowerShellのバージョンを確認する

AnsibleでWindowsを操作するためにはWindows側にPowershell3.0以上がインストールされている必要があります。
ただ、基本的にWindows Server2012R2=4.x WindowsServer2016=5.x なのでよっぽど古いバージョンを使用していない限りは何も問題無いかと思います。

PS C:\Users\Administrator> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.14393.1358
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.1358
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

セットアップスクリプトを実行してWinRMを有効化する

Ansible公式が提供しているWinRMのセットアップスクリプトをダウンロードして実行していきます。

セットアップスクリプトのダウンロード

PS C:\Users\Administrator> Invoke-WebRequest -Uri https://raw.githubusercontent.com/ansible/ansible/devel/examples/scripts/ConfigureRemotingForAnsible.ps1 -OutFile ConfigureRemotingForAnsible.ps1

セットアップスクリプトの実行

PS C:\Users\Administrator> powershell -ExecutionPolicy RemoteSigned .\ConfigureRemotingForAnsible.ps1 -SkipNetworkProfileCheck

Ansibleの設定

pipでpywinrmをインストールします
これだけです

[ec2-user@ip-172-22-68-157 ~]$ sudo pip install pywinrm

動作確認

設定が完了したので動作確認としてAnsibleでテキストファイルをWindowsServer上のディレクトリに配置できるかどうかためして見たいと思います。

コマンド実行

Ansibleサーバ上のtest.txtをWindowsServer上のC:\work\配下にコピーするコマンドを実行してみます。

$ ansible windows  -i ansible_hosts -m win_copy -a "src=./test.txt dest=C:\work\\"

Ansibleに読み込ませるhostsファイル

以下のファイルをansible_hostsとして読み込ませてコマンドを実行してみます。

[windows]
172.14.1.1

[windows:vars]
ansible_user=kabegiwa
ansible_password=wawawa
ansible_port=5986
ansible_connection=winrm
ansible_winrm_server_cert_validation=ignore

** 実行結果確認 WindowsServer上にtest.txtが無事格納されていることがわかります。

PS C:\work> dir test.txt

    ディレクトリ: C:\work

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       2018/01/16     17:22              0 test.txt

Ansible実践ガイド

Ansible実践ガイド

AnsibleでFailed to connect to the host via ssh: Permission denied (publickey).\r\nというエラーが表示されたときの対処法

Ansibileの勉強をしていたところ、以下のようなエラーが表示されてしまいました。

$ ansible -i test01_inventory.ini test_servers -m ping

localhost | UNREACHABLE! => {
    "changed": false,
    "msg": "Failed to connect to the host via ssh: Permission denied (publickey).\r\n",
    "unreachable": true
}

Ansibleではなくふつうにpingを実行したところ正常に実行できた。
なにかがおかしい…

解決策

調べてみたところ~/.ssh/配下の秘密鍵を利用して接続しに行こうとしている様子。

なので秘密鍵を利用して接続するようにコマンドを変更してみます。

$ ansible -i ansible/ansible_hosts test01_inventory.ini --private-key=./himitsu-Key.pem -u ec2-user -m ping

192.140.1.102 | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

無事pingがとおりました。
private-key=./himitsu-Key.pem-u ec2-userで秘密鍵と接続ユーザを明示してあげたところうまくいきました。

Ansible実践ガイド

Ansible実践ガイド

S3上のテキストファイルをLambda(Python)で取得する

今回はS3の中に入っているテキストファイルの内容をLambda(Python)で取得してみたいと思います。

S3上には内閣府が公表している国民の休日のcsvファイルの文字コードをutf-8に変換したものを格納しています。

↓これをsjisからutf-8に変換
http://www8.cao.go.jp/chosei/shukujitsu/syukujitsu.csv

コード

python

以下のような結果が返ってくるはずです。

['国民の祝日月日,国民の祝日名称', '2016-01-01,元日', '2016-01-11,成人の日', '2016-02-11,建国記念の日', '2016-03-20,春分の日', '2016-04-29,昭和の日', '2016-05-03,憲法記念日', '2016-05-04,みどりの日', '2016-05-05,こどもの日', '2016-07-18,海の日', '2016-08-11,山の日', '2016-09-19,敬老の日', '2016-09-22,秋分の日', '2016-10-10,体育の日', '2016-11-03,文化の日', '2016-11-23,勤労感謝の日', '2016-12-23,天皇誕生日', '2017-01-01,元日', '2017-01-09,成人の日', '2017-02-11,建国記念の日', '2017-03-20,春分の日', '2017-04-29,昭和の日', '2017-05-03,憲法記念日', '2017-05-04,みどりの日', '2017-05-05,こどもの日', '2017-07-17,海の日', '2017-08-11,山の日', '2017-09-18,敬老の日', '2017-09-23,秋分の日', '2017-10-09,体育の日', '2017-11-03,文化の日', '2017-11-23,勤労感謝の日', '2017-12-23,天皇誕生日', '2018-01-01,元日', '2018-01-08,成人の日', '2018-02-11,建国記念の日', '2018-03-21,春分の日', '2018-04-29,昭和の日', '2018-05-03,憲法記念日', '2018-05-04,みどりの日', '2018-05-05,こどもの日', '2018-07-16,海の日', '2018-08-11,山の日', '2018-09-17,敬老の日', '2018-09-23,秋分の日', '2018-10-08,体育の日', '2018-11-03,文化の日', '2018-11-23,勤労感謝の日', '2018-12-23,天皇誕生日']

解説

s3_get_objectでバケットとファイル名を指定してskyujitsu.csvを取得します。
その結果はresponseのBody部に格納されますのでそれをreadしてデコード、改行コードでsplitしています。

退屈なことはPythonにやらせよう ―ノンプログラマーにもできる自動化処理プログラミング

退屈なことはPythonにやらせよう ―ノンプログラマーにもできる自動化処理プログラミング