Terraform で構築前に知っておいた方が良いと思われる機能の紹介

qiita.com

HashiCorpTerraform を利用して、よくインフラ層の管理を行っています。 理由としては、いくつか考えられるます。

  1. 様々な IaaS に対応しているので、Terraform での書き方が分かっていれば、学習コストなどを抑えて新しい IaaS の導入ができる
  2. HCL (HashiCorp Configuration Language) は、人が読みやすい設定ファイルで初めての人が読んでもなんとなく理解ができるので、複数人で管理するDevOpsの場面に向いている
  3. Terraform Module Registry で他人が書いたソースを導入することができコストを抑えると同時に、学習することができる

などなど、様々なことがあります。(同時にデメリットの部分ももちろんあります。)

そこで、これから Terraform を導入しようとする人向けに知っておくと良いのではないかと私個人が考えている機能をユースケース別に紹介したいと思います。 (基本的には、ドキュメントを読めば書いてあることですが。。。)

似たような環境でちょっとだけ差異がある環境を作りたいのだけど…

State: Workspaces - Terraform by HashiCorp

Workspaces という機能を利用することで、だいたいの需要は満たせると思います。 必要な環境があれば、 terraform workspace new コマンドを利用して作成することができますし、定義ファイル内では、${terraform.workspace} という変数が使えるようになりますので、この変数をうまく使って環境毎の差異を吸収するようにすると良いかと思います。

ただ、Workspaces ではある処理をスキップする書き方がスマートにまだ書けないという問題があります。無理やりやろうとすると、Meta-parameterscount を使って、ある workspace の場合だけ、 countを0にするという方法で実現できると思います。

同じプロバイダー(GCP, AWS, etc.)だけど、別の設定のものを使いたいのだけど…

Configuring Providers - Terraform by HashiCorp

Terraform は複数のプロバイダーに対応しており、alias というフィールドを Provider に定義することによって、同じプロバイダーも利用することが可能になります。 GCPなどを利用している際は、環境毎にプロジェクトを分けて対応することが多いですが、DNSなどはプロジェクト横断的に利用することも多く、この機能は重宝しそうです。

複数人で実行したいのだけど…

State: Remote Storage - Terraform by HashiCorp

Terraform では対象のインフラがどのような状態であるか、Stateファイルというものを使って管理しています。この機能は事前に差分を照会したりするので、重要なファイルです。ただ複数人で実行する際は、このファイルを共有する必要があります。デフォルトではローカルにこのファイルは保存されてしまいますが、Remote state という機能を利用すれば解決できます。

Remote state で利用できる各サービスは、以下のページに記載されています。 Backend: Supported Backend Types - Terraform by HashiCorp

私個人の意見としておすすめは、S3 です。理由としては、バージョニングの機能が提供されていること、Dynamo DB と連携して実行中のロック機能を提供することが可能という点です。

既に構築済みのものがあるのだけど…

Import - Terraform by HashiCorp

import 機能を利用することによって、現在のインフラのリソースの状態をstateファイルに反映しTerraformの管理下にすることが可能です。 ただ、全てのリソースに対応が出来ていないので、PRを送るか、手動でstateファイルを編集するなどが必要になる場面もあります。

操作ミスで消えてしまうリソースがあると困るのだけど…

Resource Lifecycle - Terraform by HashiCorp

特定のリソースは、ある設定が変更された際に、作り直しが必要なものが存在します。たとえば、AWS の ec2 のインスタンスuser data などは変更があるとインスタンスを削除し新しく構築が行われます。ただ、今回は Terraform の設定ファイルのみの編集だけを行いインスタンスの再作成は、実行してほしくないという場合、以下のような書き方が可能です。

resource "aws_instance" "web" {
  ami           = "ami-408c7f28"
  instance_type = "t1.micro"
  user_data = "${template_file.userdata.rendered}"
  lifecycle {
      ignore_changes = ["user_data"]
  }
}

その他にも、lifecycle では削除することそのものを防ぐことも可能です。

さいごに

いくつか個人的に紹介したい機能を紹介させていただきました。 他にも様々な場面で有効な機能が存在します。 Terraform はインフラ系のエンジニアだけのツールではなく、様々なエンジニアとインフラ層を近づけてくれるツールだと思っています。 ちょっとでもインフラに興味があるエンジニアであれば、触ってみてください。

gRPC とは何か メモ

用語としては、ずっと前から知っていたが具体的にどのように、どのような利点があるのかなどが分かっていなかった。書籍の SRE の中でも Googleロードバランサーのシステム内で、この gRPC を利用しているとあったので、興味を持ったのでちょっと調べることにしたので、ブログに簡単にまとめておく。

www.amazon.co.jp

続きを読む

Ansible の共通処理をどこに書くの問題

普段、サーバーのプロビジョニングツールとして Ansible で利用することが多いのですが、その時いつもモヤモヤするのが共通処理をどこに書くのが正しいのだろうかという問題があります。

www.ansible.com

共通処理とは?

ここで私が考えている共通処理というのは、全部のサーバーではないが場合によっては、対象のサーバーでは同じような処理を使いまわしたいと思うような処理です。
全サーバーで共通の処理として実行するものに関しては、roles/common の配下に入れておいて各 playbook から include してあげるというのをやっている方も多いかと思いますが、今回は異なります。
また、 Ansible のディレクトリ構成を考えると、roles の下に共通処理が来ると少し気持ちが悪かと思います。 例えば、ruby をインストールするディレクトリは、 roles/ruby となってしまって、実際にサーバーの役割として配置しているディレクトリ(例: roles/api)と混ざってあまりよくない感じになってしまいます。

じゃ、どこに?

そこで無理やりの解決策として、共通処理に関しては、prefix として _ (アンダーバー)を利用することにしました。
例えば、 roles/_ruby となります。この様にすることによって、通常の role のディレクトリとは異なっていると直感的に分かります。
そして、この共通処理を各 role の task から include_role というモジュールを使って呼び出します。

include_role - Load and execute a role — Ansible Documentation

roles/api/tasks/main.yml

- name: Install ruby
  include_role:
    name: _ruby
roles
├── _ruby
│   └── tasks
│       └── main.yml
├── api
│   ├── tasks
│   │   └── main.yml

この構成にしてからは、自分としてはかなりスッキリと Ansible の処理が書けるようになりました。

さいごに

あとは、この共通処理を他のプロジェクトでも利用できるようにしても良いのかなぁと漠然と考えています。 もしこの辺りでご意見あれば、是非コメントください 🙇

子育てをしながら、どのように学習し続けるのか

この記事は、子育てエンジニア Advent Calendar 2016 の24日目の記事です。

4歳と1歳の息子がいます。webエンジニアでパパをやっています。
エンジニアという職種は、新しい事柄や基礎について学習が必要です。子どもが生まれると自由な自分の時間というものがなくなりますので、エンジニアとしては、死活問題です。
そこで自分が今、挑戦し試している方法をいくつかまとめたいと思います。だれか子育てしている人たちの参考になれば幸いです。

強制的な時間の確保

業界的に新しい技術が日進月歩のごとく目まぐるしく出て来る性質のため、牛歩並に遅くても前進し続けるように学習するのが重要です。
また、子育てというのは性質上いくらでも時間を書けることが可能です。
毎日の生活の中で、強制的な時間を確保する必要があります。
私は、通勤時間が1時間40分程度あり、そこを毎日の学習の要として活用しています。

電車内で最適な学習環境を整える

重要な学習時間を作り出すために、電車内の最適化にはお金を投資しますw

両手フリーな状態を作る

iPhoneなどスマフォは手放せません。
車内で機動力を確保するために、両手を空け他のデバイスも使えるように、スマフォについては、ネックストラップを活用しています。
私は、以下の商品を使っています。

スノーピーク(snow peak) SPアウトドアストラップ  UG090GD
スノーピーク(snow peak) (2012-03-12)
売り上げランキング: 114,141

読書はkindleマンガモデル

学習のためには、本を読む方法がありますが、技術書となると、分厚すぎて持ち歩くだけで疲れてしまいます。
また自分の学習スピードを最適化するためには、気分によって読む本を変えたりできるのが良いです。
そこで、35Gのマンガモデルを利用しています。なるべく紙の本は購入しないようになりました。Kindleの良いところは、マーキング機能です。MacKindleとも連携可能なので、電車内で印をつけて、帰ってMacで確認するということもシームレスに可能です。

f:id:urapico:20161224061302p:plain

Amazon.co.jp ヘルプ: Kindle for Macの最新バージョンをダウンロードする

f:id:urapico:20161224061907p:plain

行き帰りの車内でやることを管理する

ついついYoutubeをみたり、ダラダラしてしまうことがあるので、それを管理するために、iOSのアプリを利用しています。 見た目のUIも触り心地も気持ちがいいので、毎日触りたくなります。

Productive habits & daily goals trackerを App Store で

f:id:urapico:20161224061246p:plain

自宅の環境整備

特にWeb系エンジニアの場合、自宅のネットワークに関しては、安定・高速なことは重要です。 ネットワークが不安定だと生協の発注やCookpadに時間が取られてしまい、無駄な時間が発生してしまいます。しかも毎日ネットは使いますので、時間短縮という観点では、ネットワークの最適化は、非常に重要だと思います。
我が家も先日、Nuro化をはたして、無駄な時間やストレスが低減出来ました。

寝かしつけトラップ対策

小さい子どもを子育てしている中では、子どもが寝たあとは集中した貴重な学習時間です。電車内では、パソコンなどを使った学習は、難しいので、Web系エンジニアとしては、パソコンの前で作業する時間も重要です。
ただ、ここで非情なトラップがあります。ミイラ取りがミイラになる、寝かしつけしていたのに、パパが寝ているですw。
どんなに精神を鍛えてもこれに逆らうことは、難しいです。

Pebbleのバイブ機能を活用

一応、寝かしつけトラップ対策として、Pebbleを活用しています。Pebbleは、バイブで通知を知らせてくれる機能がありますが、アラームも同様の方法を利用できます。 子どもの寝かしつけのあと、自分が起きたい時間を2、3種類ほど設定して、なんとかミイラ状態から蘇るように対策しています。 ただ、失敗に終わる日も多いですw

Pebble Smartwatch | Smartwatch for iPhone & Android

f:id:urapico:20161224061348p:plain

おわりに

こんな感じで、日々奮闘していますが、大変ですが、まぁ我が子が可愛いというので、今後も色々と最適化をし続け家族のために自分のために、仕事がんばるぞ!!って感じです。
ありがとうございました!!

TerraformによるConsulの導入の考察

これは、Goodpatchのアドベントカレンダー 18日目の記事です。

こんにちは、Goodpatchでエンジニアをしている@urapicoです。

先日、GoodpatchのサービスのProttのインフラを専用サーバーからAWSに全て移行しました。 特に骨が折れたのは、S3の引っ越しですが。。。

今回は、HashiCorpで有名な2つのプロダクトTerraformとConsulについてです。

続きを読む

PHPのExceptionについてQiitaにちょっと書いてみた

PHPのExceptionの処理で、catchしたら、どうするのがいいのか - Qiita

これであっているのかなぁ。。。

なぜ、Symfony2が良いのか?

今まで、PHPのいくつかのフレームワークに触れる機会が、あります。

自分なりに振り返り。。。
触ったことのあるフレームワーク
触ったことのないフレームワーク(気になっているけど)
 
以下の項目を理由に、いまのところ、自分の中では、Symfony2が一番というのが結論。 
  • コード書きやすさ(保守性)
  • コード読みやすさ(保守性)
  • 設計しやすさ
  • バグ混入率
  • ドキュメントの充実
  • コミュニティの活発
  • 開発活発
  • 潮流にのっているのか
まだ、有名なCakePHPに触れていないので、今度触ってみようかと思う。 

Symfony2の最初の印象

メインの開発で利用していたsymfony1系の開発が終了するとのことで、次のメインとなるフレームワークを探していて、当たり前のように Symfony2を触り始めた。

最初の壁は、いろいろあったが、強いて言えば、アノテーション

Javaでは、現在ネイティブにサポートされている機能だが、PHPでは未対応だけれども、フレームワークでは、アノテーションを採用していた。

普段のPHPコメントアウトの領域に、いろいろと定義を記載するのは、当初はなれなかったが、使っているうちに、直感的に利用することが可能へとなっていった。 

テンプレートエンジンTwig

当初、テンプレートエンジンのtwigも厄介に感じていた。

PHPの関数とかが使えないのにストレス感じていたが、extendsなど理解が深まると同時に、素のPHPより見通しの良い書き方ができるようになってきた。

なんだか設計がワクワク

Eventなども使って、いろいろな処理を実現していくことになれてくると同時に、Symfony2で設計すること自体が楽しくなってきてしまう魔力があります。

 

最後に

まぁ、Symfony2がおすすめということです。