2018-08-09

【2018年8月9日時点の話】ACMのCloudFormationテンプレートはDNS検証を選択できない話

aws

この記事は2018年8月9日時点の情報になります。
最新の情報をご確認下さい。

本エントリーは下記バージョンで動作確認しています。

AWS CLI	2.121.1	aws-cli/1.15.71 Python/2.7.10 Darwin/17.6.0 botocore/1.10.70

ACMのCloudFormationテンプレートでDNS検証を選択できないんですね！
いやー、初めて知りました！今後のアップデートに期待ですね！

例えば、下記のテンプレート例：

# ※よくない記述例です。
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  Certificate:
    Type: AWS::CertificateManager::Certificate
    DeletionPolicy: Retain
    Properties:
      DomainName: abc.net
      DomainValidationOptions:
        - DomainName: abc.net
          ValidationDomain: DNS

上記のように記述すると、"ValidationDomain"の項目で構文エラーが起きてロールバックされます。

試しに、ValidationMethodと追記した例：

# ※動かないです。
Resources:
  Certificate:
    Type: AWS::CertificateManager::Certificate
    DeletionPolicy: Retain
    Properties:
      DomainName: abc.net
      DomainValidationOptions:
        - DomainName: abc.net
          ValidationMethod: 'DNS'

上記のように記述した場合、
"Encountered unsupported property ValidationMethod"というメッセージを残しロールバックされました！

いろいろ調べたところ、2018年8月9日時点でもサポートされていないようで。

https://forums.aws.amazon.com/thread.jspa?messageID=821952

CloudFormationで全てのリソースを管理できそうにない話

CloudFormationによるインフラストラクチャーのテンプレート化はとても気に入ってるので、
基本的にHandson環境や仕事のProduction環境はテンプレートを作成しているのですが、
テンプレートでリソースを管理できないとなると、ちょっとつらたんですね。
確か、EC2で使用するキーペアもCfnテンプレートがなかったような。

と言っても、頻繁に更新するかはリソースによりけりなんですけどね。

AWS CLIも活用する

このような場合は、AWS CLIを活用してコード化してもよさそうです。
記述例：

aws acm request-certificate --domain-name <ドメイン名> \
--validation-method DNS --region us-east-1 --profile <プロファイル名>

以上、小ネタでした！

2018-08-06

AWS VPCのCIDR範囲とIPの総数について

aws

調べても載ってない or 探しにくいシリーズ的な。
先日、AWS認定試験のワークショップに参加したのですが、
その時に共有された情報です。エントリー残しておきます！

VPCで指定できるCIDR範囲
通信のソースや送信先を指定する場合のCIDR範囲
CIDRをIPアドレスに展開する便利サイト

VPCで指定できるCIDR範囲

指定できるプレフィックス長：/16から/28
CIDR/IPの総数

CIDR	IPの総数
/16	65,536
/17	32,768
/18	16,384
/19	8,192
/20	4,096
/21	2,048
/22	1,024
/23	512
/24	256
/25	128
/26	64
/27	32
/28	16

通信のソースや送信先を指定する場合のCIDR範囲

すべてのプレフィックス長(/0 ~ /32)を指定可能
特殊な表記
- 0.0.0.0/0：IPアドレス全体を表す
- xx.xx.xx.xx/32：特定の1つのIPアドレスを表す

CIDRをIPアドレスに展開する便利サイト

AWSのVPC設計時に下記のサイトを使うと便利かも？
ipvx.info

以上です！

2018-08-01

Raspberry PIをモニタレスで使えるように無線LANからSSH接続できるまで設定した

Raspberry Pi テクニカルナレッジ

個人的備忘録になります。
Raspberry Pi3 Model Bのコンプリートセットを購入しました。
http://amzn.asia/d/dzcufGg

コンプリートセットですので、OSは付属のSDカードにインストール済みですが、
多分また何回かセットアップすることになると思うので、備忘録がてらエントリーを残しておきます。
※お使いの製品バージョンによっては手法が異なる場合があります。

パッケージ更新
ssh有効化
公開鍵・秘密鍵の生成とダウンロード
固定IPの設定
ssh接続の確認
ついでにGUIをオフにしておく

パッケージ更新

sudo apt-get update
sudo apt-get upgrade

※wolfman-engineでハッシュサムが適合しませんとメッセージが表示されたが、
今回はとりあえずスルー。後で使わないパッケージならpurgeする。

ssh有効化

sudo su
cd /boot/
touch ssh

ラズパイを再起動後、
メニューから「設定」->「Raspberry Piの設定」->「インターフェイス」を表示。
SSHが有効になっていることを確認する。

公開鍵・秘密鍵の生成とダウンロード

# rootユーザーを終了する
exit
# 鍵生成
ssh-keygen -t rsa
# authorized_keysに生成した公開鍵を記述する
vi ~/.ssh/authorized_keys
# 秘密鍵をクライアントにダウンロードさせるため、一時的にパスワード認証を有効にする
vi /etc/sshd/sshd_config
# 56行目付近 コメントアウトを外してyesにする
PasswordAuthentication yes

ラズパイを再起動後、
scpで秘密鍵をダウンロードする。今回はMacでダウンロード

# ifconfigでwlan0(無線LAN)のIPアドレス情報を確認し、SCPダウンロードする
scp pi@IPアドレス:/home/pi/.ssh/id_rsa ./

固定IPの設定

# dhcpcd.confファイルの編集
sudo vi /etc/dhcpcd.conf
# 下記を追記する
interface wlan0
static ip_address=192.168.3.83/24
static routers=192.168.3.1
static domain_name_servers=192.168.3.1
# セキュリティ強化のため、パスワード認証を無効にする
vi /etc/sshd/sshd_config
# 56行目付近 noにする
PasswordAuthentication no

「ip_address」の項は好きなIPアドレスを指定する。ただし、ルーターによってIP範囲が指定されている場合があるので要確認。
「routers」「domain_name_server」にはルーターのIPアドレスを指定する。

私の場合は、ソフトバンク光なので下記のURLで管理画面にアクセスし、ルーターのIPアドレスを確認した。

http://172.16.255.254

ssh接続の確認

ssh -i ./id_rsa pi@192.168.3.83

f:id:yasay:20180801050323p:plain
接続できました！

ついでにGUIをオフにしておく

使うことないと思うので。

sudo raspi-config

「3 Boot Options」->「B1 Desktop / CLI」から「B2 Console Autologin」を選択する。
再起動して、コンソール画面が表示されればOK。

以上です！

2018-07-26

JJUG ナイトセミナー「Elasticsearch特集」行ってきましたレポート！

Java JJUG Elasticsearch コミュニティ活動

JJUGナイトセミナーに行ってきました！
jjug.doorkeeper.jp

初めて日本オラクル本社に行きました！
今回はレポート少なめですが、書き殴っていきます。

Elastic Stackで始めるJavaアプリのパフォーマンス監視
はじめてのElasticsearchクラスタ
所感

Elastic Stackで始めるJavaアプリのパフォーマンス監視

speakerdeck.com

Beats
- データを集めて後ろに投げることが主目的で軽量である。Go言語で作られている。
- Libbeat
  - カスタムbeatsのためのAPI フレームワーク
  - Packetbeat, Metricbeat, Winlogbeat, Auditbeat, Filebeat, Heartbeat
Logstash
- Rubyで作られている。データ加工パイプライン
Elasticsearch
- 全文検索エンジン, Apache Luceneを使っている。
Kibana
- Elasticsearchのデータを可視化。可視化と分析。
- サンプルサイト：
  - https://demo.elastic.co

Elastic APM
- アプリケーションパフォーマンスモニタリング
  - アプリケーションの内部パフォーマンスを可視化
- ユーザーアクションを計測するRUMというものもある。現在はJavascriptのフロントエンド用
- APMサーバーが必要。x-pack basicでKibana API UIを構築
  - GitHubでソースが公開されているけど、オープンソースではない。無料では使える。
- Python, Node.js, Rubyがサポート。JS, Go Javaはβ提供。
- elasic-apm-agentでmaven検索で取得できる。

はじめてのElasticsearchクラスタ

はじめてのElasticsearchクラスタ from Satoyuki Tsukano

www.slideshare.net
結構Deep Diveなセッションでしたので、スライド参照したほうがよいです。

所感

視覚的にアピールできるKibanaはセミナーでとりあげられることが多い。
しかしながら、モニタリングツールは他にもたくさんある。
特にIaaSを利用しているなら標準モニタリングもあるだろう。
既に可視化できる環境を持っているのならば、
Kibanaをモニタリング目的だけで導入するというのは、
判断する人(上司)を振り向かせることが難しいと思う。

むしろ、大事なのは中核をなす機能であるElasticsearchだ。
GitHubの検索に使われているという実績は大きい。

私は今まで全文検索エンジンを利用した業務システムを構築した経験はないが、
この機会に各ソフトウェアやエンジンについてより深く知りたい。

Elasticsearch - Wikipedia
Apache Lucene - Wikipedia
Apache Solr - Wikipedia

ナイトセミナー楽しかった！また来月いけたらいいなぁ。

2018-07-06

Spring BootのGradleプロジェクトをJenkinsでCIしてみる

Vagrant テクニカルナレッジ

本エントリーは下記バージョンで動作確認しています。

Jenkins	2.121.1
Spring Boot	2.0.1
Java	OracleJDK 8

GitHubで管理しているSpring Bootプロジェクトを
Jenkinsでビルドし、ユニットテストを実施してみました。
その時の設定箇所を記載します。

設定箇所

新規ジョブ作成時は「フリースタイル・プロジェクトのビルド」を選択

f:id:yasay:20180706142041p:plain

ソースコード管理でGitHubのリポジトリ情報を入力

今回はGitHubからソースをダウンロードしてビルドしますので、
Gitを選択します。リポジトリURLと認証情報を入力します。
認証情報はGitHubのユーザーIDとパスワードを使用しました。
f:id:yasay:20180706142656p:plain

ビルド・トリガを指定。今回は定期的に実行。

cronの書式で入力する。今回は30分に一度ビルドが走るように設定。
f:id:yasay:20180706142959p:plain

ビルド環境の設定

「ビルド開始前にワークスペースを削除する」をオン。
この設定をオンにした経緯は、ビルド後の処理である「テスト結果の集計」で
日付の古いxmlファイルを見ようとしてビルドエラーになってしまったためになります。
f:id:yasay:20180706154355p:plain

ビルドタスクの追加

「ビルド手順の追加」 -> 「Invoke Gradle script」を選択
「Use Gradle Wrapper」を選択し、「Make gradlew executable」にチェックを入れる。
- 今回はGradle Wrapperを使用しています。"gradlew bootJar"などのコマンドを実行することで、Gradleをインストールしていなくてもビルドなどを実行することができます。
Tasksの入力項目に"bootJar"と入力します。

f:id:yasay:20180706143705p:plain

テストタスクの追加

前項のビルドタスクの追加と同様の手順を行った後、
Tasksの入力項目に"test"と入力します。
f:id:yasay:20180706143853p:plain

JUnitテスト結果の集計タスクを追加

「ビルド後の処理の追加」 -> 「JUnitテスト結果の集計」を選択
画像を参考にして、テスト結果xmlファイルのパスを指定する。

f:id:yasay:20180706154720p:plain

さっそくジョブを起動してみます。成功しました！

f:id:yasay:20180706144751p:plain

ユニットテストの結果を確認することも可能です。

testコマンドは標準でhtml出力されるようで、下記の手順で閲覧することが可能です。

ジョブのワークスペースを選択する
「build / reports / tests / test」に移動する
index.htmlを選択する。

テストサマリーが表示されました！

今回はVagrantとDockerで起動したJenkinsサーバー上で動かしました。
気軽にCIを実践できるよい時代になったものですね！

以上です！

2018-07-06

VagrantでJenkinsのDocker Imageを起動する

Docker Vagrant テクニカルナレッジ

手元のPCがあれば、いつでも始められるCI！

Vagrantの初期セットアップは下記の記事をご参照下さい。
xblood.hatenablog.com

DockerでJenkinsを起動する

Docker Imagesの取得

sudo su
# JenkinsのLTSイメージを取得する
docker pull jenkinsci/jenkins:lts

Jenkins Imageをバックグラウンド起動する

# -vオプションで、コンテナが停止した時のためにJenkins関連ファイルを永続化する
# --restartオプションで、vagrantが起動した時に自動起動するように 
docker run -d -v jenkins_home:/var/jenkins_home -p 8080:8080 -p 50000:50000 -e "TZ=Asia/Tokyo" --restart=always jenkinsci/jenkins:lts

自動起動を停止させたい場合

# Nameをgrepで取得する
sudo docker inspect -f "{{.Name}} {{.HostConfig.RestartPolicy.Name}}" $(sudo docker ps -aq) | grep always
# update --restart=noを設定する。引数となるのはコンテナのNAME
sudo docker update --restart=no $Name

コンテナIDを確認する

docker ps
# 以下のような結果が表示される
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS              PORTS                                              NAMES
850da8fef9f2        jenkinsci/jenkins:lts   "/sbin/tini -- /usr/…"   7 minutes ago       Up 7 minutes        0.0.0.0:8080->8080/tcp, 0.0.0.0:50000->50000/tcp   nostalgic_lamport

コンテナIDを指定してコンテナ内に入り、初期パスワードをメモする

# execコマンドを使用
docker exec -i -t $PROCESSID /bin/bash

# 初期パスワード確認
cd
cd secrets/
cat ./initialAdminPassword

ブラウザからアクセス

メモしておいた初期パスワードを入力し、セットアップを進めます。
無事に初期画面までたどり着きました！
f:id:yasay:20180705145210p:plain

以上です！この続きのエントリーは
「Spring BootのGradleプロジェクトをJenkinsでCIしてみる」になります！
xblood.hatenablog.com

参考サイト

Ubuntuにdockerをインストールする - Qiita
docker/README.md at master · jenkinsci/docker · GitHub

2018-07-05

AWS CodeStarで遊ぶ！お手軽に継続的デプロイメント！

aws

AWS Code Starは継続的デプロイを実践する上での近道になるとの認識です。
なにはともあれ、とりあえずCode Starを触ってみて継続的デプロイを実践してみます。

Code Starは複数のCloudFormationスタックの集合体

ですので、Code Star自体をCloudFormationでプロビジョニングするという方法は、
現時点(2018/7/5)では存在しないという認識です。
参考サイト：
dev.classmethod.jp

プロジェクト・テンプレート

これ見るだけでもわくわくするぞ！今回はPHP(Slim)のElastic Beanstalkを選択。
https://dev.classmethod.jp/cloud/aws/about-cloudformation-in-aws-codestar/
f:id:yasay:20180705110056p:plain

GitHub リポジトリを使う

今回はリポジトリにGitHubを指定。プロジェクトを作ってみます！
f:id:yasay:20180705110349p:plain

数分でCodeStarのセットアップが完了！

数分でCodeStarプロジェクトのセットアップが完了します！これはすごい！お手軽！
f:id:yasay:20180705111615p:plain

Public IPにブラウザでアクセスしてみる。

繋がった！Hello World!
f:id:yasay:20180705111915p:plain
すぐ繋がるということは、既にElastic IPやSGがプロビジョニングされているということですね。
確認してみると、SGはフルオープンになっていたので、IP制限しました。ネットワーク転送料金怖い。

Beanstalkのアプリケーションエンドポイントでもアクセスできます。

今回はElasic Beanstalkでプロビジョニングしたので、
下記のようなエンドポイントでもアクセスできました。

# URLの例
http://php-beanstalkapp.amXXXXXXXX.ap-northeast-1.elasticbeanstalk.com/

早速プッシュして、継続的デプロイメントを試してみる。

今回はIntelliJ IDEAにPHP プラグインを入れて編集してみました。
"Hello CodeStar!"に変えてみます。
f:id:yasay:20180705113309p:plain

すぐさま、CodeStarにコミット履歴が表示される。

普段この管理画面を見る事自体、あまりないと思いますが、リアルタイム性すごい。
すぐにコミット履歴が表示されました。
f:id:yasay:20180705113513p:plain

継続的デプロイメントが発生！

すぐにデプロイが開始されました。早速エンドポイントにアクセスしてみましょう。
f:id:yasay:20180705113720p:plain

Beanstalkのエンドポイントに接続してみる。変更された！

ちょっと感動した！
f:id:yasay:20180705113836p:plain

気になった点

VPCの指定はできないの？ -> できました。

初回はデフォルトのVPCで起動してしまいました・・。
「プロジェクト詳細の確認」画面で、「Amazon EC2の設定を編集」を
クリックすることで指定することができました。
f:id:yasay:20180705114603p:plain

所感

ここまでの作業で30分もかかってないところがすごくて、
本当にAWSリソースのプロビジョニングとアプリケーションデプロイの環境が
瞬時に作成できる。スモールスタートはこれでいいんじゃないかと思う。

しかしながら、懸念は残る。結局AWSのコードサービスを使いこなせるかが鍵かな。
開発環境ならいいんですが、プロダクション環境とかになると話が変わってきますよね。
プロダクション環境だと、サービスが稼働しているわけですから、簡単にはデプロイできないです。
そういった場合のローリングアップデートの方法を知るということは、
AWSのコードサービスを使いこなすということだと思うので、
属人化が発生する可能性がある点かな。

また、AWSのコードサービスに浸かっちゃうと
もし仮にAWS以外でやりたいって場合にどうするの？という話も出てくると思います。
所謂ベンダーロックインというやつですね。~~AWSにならベンダーロックインされてもいいわぁ。~~

さくっと作ってさくっとデプロイするにはCodeStarは最強ですが、
実際に運用するとなるとベスト・プラクティスが必要になる気がしました。
だって、実際の運用だとサブネットをプライベート化するじゃないですか。
CodeStarで作られるVPCのネットワーク構成はその辺り考慮されて作られるわけではないんですよねぇ。

以上です！
CodeStarシリーズのエントリーは続くかもしれません、続かないかもしれません！w

例えば、下記のテンプレート例：

試しに、ValidationMethodと追記した例：

いろいろ調べたところ、2018年8月9日時点でもサポートされていないようで。

CloudFormationで全てのリソースを管理できそうにない話

AWS CLIも活用する

VPCで指定できるCIDR範囲

通信のソースや送信先を指定する場合のCIDR範囲

CIDRをIPアドレスに展開する便利サイト

パッケージ更新

ssh有効化

公開鍵・秘密鍵の生成とダウンロード

固定IPの設定

ssh接続の確認

ついでにGUIをオフにしておく

Elastic Stackで始めるJavaアプリのパフォーマンス監視

はじめてのElasticsearchクラスタ

所感

設定箇所

新規ジョブ作成時は「フリースタイル・プロジェクトのビルド」を選択

ソースコード管理でGitHubのリポジトリ情報を入力

ビルド・トリガを指定。今回は定期的に実行。

ビルド環境の設定

ビルドタスクの追加

テストタスクの追加

JUnitテスト結果の集計タスクを追加

さっそくジョブを起動してみます。成功しました！

ユニットテストの結果を確認することも可能です。

DockerでJenkinsを起動する

Docker Imagesの取得

Jenkins Imageをバックグラウンド起動する

自動起動を停止させたい場合

コンテナIDを確認する

コンテナIDを指定してコンテナ内に入り、初期パスワードをメモする

ブラウザからアクセス

参考サイト

Code Starは複数のCloudFormationスタックの集合体

プロジェクト・テンプレート

GitHubリポジトリを使う

数分でCodeStarのセットアップが完了！

Public IPにブラウザでアクセスしてみる。

Beanstalkのアプリケーションエンドポイントでもアクセスできます。

早速プッシュして、継続的デプロイメントを試してみる。

すぐさま、CodeStarにコミット履歴が表示される。

継続的デプロイメントが発生！

Beanstalkのエンドポイントに接続してみる。変更された！

気になった点

VPCの指定はできないの？ -> できました。

所感

GitHub リポジトリを使う