S3+CloudFrontをTerraformで設定してCircleCIで更新する

「TerraformでS3+CloudFront+SSL/TLS証明書 w/ ACMを設定してHugoで作ったstaticなWebサイトをCircleCIで自動deployする」やつができた。

できたもの

普通のいかにもHugoで作ったWebサイトができた。
もう2018年なので手オペなどせずInfrastructure as Codeで構築かつCIでコンテンツdeployです。
中身はまだない。
きっと酒とメシについての何かが書かれるのでしょう。

f:id:mazgi:20180215023829p:plain https://sakemeshi.love/

これはそもそも先日開催したハッカソンでやろうとして途中までしか進められなかったので、その補習も兼ねてます。

なお次回ハッカソンはGoです!

denatechstudio.connpass.com

構成

図を描く気力がなかったのでテキストで。

インフラ構築編

Terraformで以下を行なっている。

  1. Route 53にドメインのゾーン情報を登録する
  2. コンテンツ更新用のIAMグループとIAMユーザーを払い出す
  3. コンテンツ格納用のS3バケットを作る
  4. ACMでSSL/TLS証明書を発行する
  5. CloudFront distributionを設定する(ACMの証明書使いたいので)
  6. CloudFront distributionをRoute 53に登録する

コンテンツ更新編

GitHubへのpushをトリガーにCircleCIで以下を行なっている。

  1. HugoでstaticなWebコンテンツ生成する
  2. 生成したWebコンテンツをS3に同期する
  3. CloudFrontのキャッシュをクリアする

GitHub

GitHubで以下を管理している。

  • sakemeshi.terraform
    • Terraformリポジトリ
    • 中身はRoute 53にドメインのゾーンを登録してmoduleを呼び出しているくらい
    • AWSのcredential等は sakemeshi.terraform-secret リポジトリに置いてsubmoduleとして参照している
  • terraform-aws-static-website
    • 自分用Terraform module
    • S3+CloudFrontでstaticなWebサイトを作るもろもろが詰まっている
  • (private) sakemeshi.terraform-secret
    • AWSのcredentialなどが入っている
    • credential store導入とかはまた今度
  • (private) sakemeshi.content
    • HugoによるWebサイトの中身
    • このリポジトリのmasterにpushするとCircleCIが動いてS3にdeployされる

つくりかた

コンセプトとしてはWebUIを手でぽちぽちしたくないのでTerraformでInfra as Codeします!

AWS Webコンソールぽちぽち

最初からコンセプトに反するようだが2018年時点では手でポチポチすることもまだ必要なのです。(あるいはCLI)
作るものは2つ。

Terraform 実行用 IAM User

terraform-admin という名前で AdministratorAccess をattacheしたIAMユーザーを作る。
credentialも払い出して、今回の場合は sakemeshi.terraform-secret リポジトリにpushしておく。

f:id:mazgi:20180215033043p:plain

tfstate 格納用 S3 Bucket

Terraformは設定したクラウド環境の状態を tfstate というファイルで管理するのでそれを格納するS3バケットを作る。

バケット名は ${AWSアカウント名}-terraform としてバージョニングを有効にする。
先ほど作ったIAMユーザー terraform-admin からアクセスできれば良い。

f:id:mazgi:20180215033214p:plain

詳しくは以下参照。

Backend Type: s3 - Terraform by HashiCorp

Infra as Terraform

インフラをコードで書く

Terraformで構築するもろもろは専用のGitHubリポジトリを作って terraform.tf に書く。
先述の通りここで公開している。

github.com

主な内容は以下の通り。

  • prepare.sh
    • terraformバイナリのダウンロードと展開
    • 必要な環境変数のexport
    • なお命名は職場の文化に由来する
  • terraform.tf
    • Terraformで行いたいもろもろ
    • ただしほとんどはmoduleに追い出しているので、実際の内容はRoute 53のゾーン設定とmoduleの読み出し程度
  • terraform.tfvars
    • 後述のprivateなcredentialリポジトリ内へのsymlink
    • AWSのACCESS_KEYやSECRET_KEYなどが書かれている

terraform.tf で参照しているmoduleは公開しているが後述のエラーやリージョンが固定などの残課題がある。
Terraform Module Registry

先述の通りTerraformを実行するIAMユーザーのcredential等は別のprivateリポジトリを作って配置している。
公開できないが中身はこの程度。

f:id:mazgi:20180215043508p:plain

Terraform 実行

ようやくTerraformを実行できる環境が整ったので実行!
なお prepare.sh は環境変数をexportするので必ず source する。

$ source prepare.sh
$ bin/terraform apply

実行すると初回はもろもろのリソースが作られ、1件のエラーが発生する。
2回目以降はこのように1件のエラーが発生する。。
後述する。

f:id:mazgi:20180215035427p:plain

細かいことを書くと今回のドメイン自体はRoute 53で管理していないため、別途ネームサーバーをRoute 53に向けておく等の手順が必要です。

CircleCIで自動build && deploy

Terraformで空のWebサイトができたので中身を作っていく。

GitHubリポジトリを用意しておもむろに hugo new site . する。
適当なテーマをsubmoduleとして追加する。
Quick Start通り。

Hugoは今後がんばることにして今回はCircleCI 2.0をがんばる。
結論を書くとこういう .circleci/config.yml を書いた。
ハマった。

そのほかは本当に hugo new site . したまま。

f:id:mazgi:20180215045406p:plain

何はともあれこれでCircleCIでのWebサイトのビルドとS3への同期が行えるようになった!めでたい!

f:id:mazgi:20180215045503p:plain

おわりに

ということで(ほぼ)手でぽちぽちせずにInfrastructure as CodeでstaticなWebサイトが作れたし更新の仕組みもできた!やったね!

ポイント

以下あまり書けてないので機会があったら書く。

Terraform

  • 最近のTerraformは terraform init が必要
    • その作業ディレクトリでの初回実行やmoduleのバージョン上げた際など
  • 最近のTerraformは terraform apply したあと本当に実行するか聞いてくる
    • そのため terraform apply[ENTER] してコーヒーを買いにいくと何十分後に戻っても Do you want to perform these actions? というメッセージが出迎えてくれる(もちろんあなたのクラウド環境には何も変化はない)
    • terraform apply -auto-approve というわるいオプションがある
  • tfstate格納用S3バケット(S3 backend)を使うためには環境変数or ~/.aws 内にcredentialが必要
    • 私は prepare.sh の中でexportしている(ので必ず source する)
  • ACMの検証が従来のメールだけではなくDNSでもできるようになっていてTerraformでも対応していた

CircleCI 2.0

  • Docker便利だけども
    • 使うDockerイメージにもよるが当然 curlgit も入ってなかったりする
    • 自分用Dockerイメージ作りたくなる
    • 開発環境がDocker Hubに公開できるDockerイメージで完結している場合は便利そう
  • checkoutgit clone --recursive 相当の機能がない(?)

(特に)ハマりどころ

terraform apply 時の aws_acm_certificate_validation エラー

terraform apply する際に毎回このエラーが発生する。

Error: Error applying plan:

1 error(s) occurred:

* module.static-website.aws_acm_certificate_validation.website: 1 error(s) occurred:

* aws_acm_certificate_validation.website: Certificate needs [VALIDATON_RECORD.YOURDOMAIN VALIDATON_RECORD.YOURDOMAIN] to be set but only [VALIDATON_RECORD.YOURDOMAIN] was passed to validation_record_fqdns

これ YOURDOMAIN*.YOURDOMAIN でバリデーションレコードが同じで、Route 53上は1レコードしかないものをTerraformのAWS providerが2レコード返ってくることを期待しているように見えるんだけどどうしたものか。

CircleCI 2.0 で attach_workspace するために ca-certificates パッケージが必要

前フェイズで永続化したワークスペースを後フェイズで attach_workspace して取り出すために ca-certificates パッケージ必要なのはハマった。
こちらの記事に助けられた。
CircleCIでx509という証明書エラーに遭遇したときの対処 - Qiita

それはそうと再掲するが .circleci/config.yml がこんな長さになった。つらい。
workflowとしてbuildとdeployが分かれるのは綺麗だけども。。

gist.github.com

ともかくこういうサイトをいくつか作りたいニーズがあったのでやっていきます。

簡易な技術ドキュメントをHugoで書くと便利だった

サンプルコードのドキュメントをHugoで書いてサンプルコードと一緒に配ったら便利そうだったのでやってみた。

gohugo.io

やりたいこと

仕事で他社さんにサンプルコードとドキュメントをセットでお渡ししたいのだけど社ではGitHub Enterpriseを使っているのでリポジトリを直接見ていただくことが難しいケースがある。

規模が大きいプロジェクトならSphinx使うと(やる気次第で)いくらでも綺麗なドキュメントが書けそうではあるけど、規模がそれほどじゃないうちはサクッとMarkdownで書いて、でもソースコードとドキュメントが整合性取れててほしいという気持ちになる。
(今はSphinxもMarkdownで書けるそうだ、最近知った)

そもそも(私は)ドキュメント書きたくないので、できるだけスクリプトの提供やソースコードコメントで賄って文章量は最小限に抑えたいというモチベーションもあった。

そこで以下のような作戦を考えた。

さくせん

  • ドキュメントはHugoでプレビューしながらMarkdownで書く
  • 生成したHTMLは /docs ディレクトリに突っ込む
  • 社内向けにはGitHub PagesでmasterのHEADをホスティングする
  • 社外向けには最新リリースのアーカイブを提供する

プレビューできるから書くの楽だし、tag打てるからソースコードとドキュメントの整合性も取りやすい。きっと便利!

できたもの

リポジトリはこちら。

github.com

GitHub Pagesはこちら。

Example Document with Hugo

テーマはこちらを使わせていただいた。
サイドバーでエントリが一覧できて技術ドキュメントらしさがある。

github.com

工夫

設定ファイルはこれ。

  • 以下で生成したHTML内のリンクが / からの相対PATHになるふいんき(ちゃんと調べていない)
    • baseURL = "/"
    • relativeURLs = true
    • uglyurls = true
  • themeの指定
baseURL = "/"
languageCode = "en-us"
DefaultContentLanguage = "en"
title = "Example Document with Hugo"
publishDir = "../docs"
relativeURLs = true
uglyurls = true
theme = "docdock"

[params]
themeVariant = "gray"

また、この設定ファイルとドキュメントのソースコード(Markdown他)を /docs.source に置き、 publishDir = "../docs" と設定することでリポジトリのrootにあまりファイルを置かないようにしている。
これはこのリポジトリにサンプルコードも同居する想定であり、rootにファイルが増えて見通しがわるくなることを避けるため。

HTMLを生成してcommitしてpushしてtagを打ったものがこちら。

Release v0.0.1 · mazgi/example-document-with-hugo · GitHub

アーカイブをダウンロードして手元で開くとこんな感じで index.html が見える。
アーカイブファイルにも展開後のディレクトリにもバージョンナンバーが含まれわかりやすい。

f:id:mazgi:20171207195147p:plain

index.html もリンク先のドキュメントもブラウザで表示できる。便利。

f:id:mazgi:20171207195157p:plain

EC2 P3で使えるChainerMN入りのDockerイメージを作った

sonots先生によるこの記事をやってみたという話です。

qiita.com

概要

Dockerfileはここにあります。

github.com

ベースはNVIDIAさんのオフィシャルイメージです。

https://hub.docker.com/r/nvidia/cuda/

実行結果

ChainerMNのexampleを試した結果はこちら。
今のところシングルNodeシングルGPUとシングルNodeマルチGPUしか試してないです。

gist.github.com

手順はこちらの通りなんですが時間が取れていない...

docker (nvidia-docker) を使ってマルチノードで ChainerMN を実行する方法(仮) - Qiita

P3じゃなくても動くはずですが、ホスト側にGPUとnvidia-dockerは必要です。
今回は社の環境で試したのでsonots便利先生環境の恩恵を受けてます🙏

blog.livedoor.jp

イチから構築する場合はこういう記事が参考になりそう。

chie8842.hatenablog.com

経緯とか

めでたく記事も出たので色々言えるようになったのですが、実はありがたいことにP3の先行検証というのをさせていただいてました。
(なおイベント当日はカメラマンしてました)

engineer.dena.jp

この検証時点ではChainerMNではなくChainerで、環境もVM上に直接作ってたのですが、その後部内から「Dockerイメージになってたほうが便利」とフィードバックいただき先行者の記事を参考に手探りしてる状況です。
私はMLわからないマンなのですが、最初 cuDNN 7 + CuPy 1.0.3 で環境作ろうとしてバージョンが合わなくてどうしよ!と思ってたら「今日 cuDNN 7 対応の CuPy 2.0 リリースするよ!」と教えていただいたりとか、この業界本当に数時間単位で進歩しててすごい。

こういう用途だとコンテナほんと便利なんですけど、でもDockerイメージの命名むずかしい。
mazgi/cuda-cv:9.0-cudnn7-devel-ubuntu16.04 じゃなくて、
mazgi/cuda-cv-9.0-cudnn7-devel-ubuntu16.04:latest とかにしたほうがいいのかな(長い)。
そもそもの話としては実質Chainer & ChainerMNイメージなのでそういう名前にすべきだし(さらに長くなる)。

Adobe CCのライセンスを別のPCに移す方法(ライセンス認証解除→再認証)

Adobe CCが不要なPCの認証を解除して、使いたいPCで何かしらのアプリを起動すれば認証されて使えるようになる。
PC買い替えなどのタイミングで必要になるが、そういうときは大体ライセンス認証解除の手順を忘れているのでメモ。

手順

認証解除の手順を3行で。
なお認証解除はWeb上での操作なので、使うPCはなんでもいい(はず)。

  1. https://accounts.adobe.com/plansを開く
  2. 「プランを管理」をクリック
  3. 「ライセンス認証したデバイス」から不要な方のデバイスを削除

ここまでできれば、あとはAdobe CCを使いたいPCでPhotoshopやIllustratorなどのアプリを起動すれば認証され使えるようになる。

f:id:mazgi:20170212015541p:plain

f:id:mazgi:20170212015557p:plain

ちゃんとAdobeのヘルプに書いてあるのだが、公式ドキュメントなので「ライセンス認証とは?」やスタンドアローン版の説明も併記されていて文量が多いので簡単にまとめてみた。

helpx.adobe.com

Hadoop黙々会を始めました

@usaturnさんと一緒に「Hadoop黙々会」を始めました。 hadoop-bootup.connpass.com 私の思惑としては「エンジニアたる者、何歳になっても学び続けないとね。でも機会を作らないとなかなか集中して学べないので人を巻き込んでイベントにしてしまおう!」といったところです。

Read more

NISSAN×DeNA @ dots. #23x に行ってきました

追記

当日のツイートをTogetterにまとめさせていただきました! togetter.com


dots.さんで「NISSAN×DeNA 車は、モノ<プロダクト>なのか、コト<サービス>なのか。当事者たちから見える風景を語る。」というイベントが開催されたので「えっ?日産の方とDeNAの方がDeep Learningや機械学習について語るの!?」と分かりやすく興味喚起されて伺ってきました!

eventdots.jp

ハッシュタグ#23xで当日のツイートが一覧できます。
(言語を日本語にした方が見やすいかもしれません)

Read more

【SELECK掲載記念】AnsibleでPartitionを切る!

追記

さくらのクラウドについて取材していただいた記事も公開されました!
合わせてご覧ください!!

さくらのクラウドで「尖ったインフラ環境」を構築。カスタマイズに強い、その実力とは | SELECK


本編

先日「SELECK(セレック)」様にAnsibleの活用事例をインタビューいただきました。

seleck.cc

素晴らしい記事にしていただいたのでせっかくなら何かネタになりそうな実例をご紹介したいと考えた結果(?)、バッドノウハウが詰まったパーティションの切り方をご紹介したいと思います!

Read more