読者です 読者をやめる 読者になる 読者になる

雑記

インフラのことだったりプログラムのことだったりどうでもいいこと書いたり。要は雑記。

Ansibleのelasticsearch_pluginモジュールをElasticSearch5系で使う

Ansible2.0からモジュールが提供されている http://docs.ansible.com/ansible/elasticsearch_plugin_module.html

が、ElasticSearch5系だと動かない。。

TASK [elasticsearch : install elasticsearch plugin] ****************************
failed: [test] (item=analysis-kuromoji) => {"failed": true, "item": "analysis-kuromoji", "msg": "A tool for managing installed elasticsearch plugins\n\nCommands\n--------\nlist - Lists installed elasticsearch plugins\ninstall - Install a plugin\nremove - Removes a plugin from elasticsearch\n\nNon-option arguments:\ncommand              \n\nOption         Description        \n------         -----------        \n-h, --help     show help          \n-s, --silent   show minimal output\n-v, --verbose  show verbose output\nERROR: timeout is not a recognized option\n"}

timeoutオプションがないとのこと。

無効化するオプションもないけど、ソースを見てみるとtimeoutを定義してなければオプションがつかないみたい。

https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/database/misc/elasticsearch_plugin.py#L150-L151

というわけでtimeoutをnullに設定すればいける。

- name: install elasticsearch plugin
  elasticsearch_plugin:
    plugin_bin: /usr/share/elasticsearch/bin/elasticsearch-plugin
    timeout: null
    name: analysis-kuromoji
    state: present

Bitbucket PipelinesでAmazonECRのDockerImageを使う

PipelinesではデフォルトではDockerHubを利用するのですが、別のレジストリサービスを使うこともできます。 というわけでECRに置いたイメージを使ってみました。

bitbucket-pipelines.ymlの設定

imageの設定を以下のようにします。

image:
  name: xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/sample-containert:latest
  username: AWS
  password: $ECR_PASSWORD
  email: none

※nameは自分のコンテナのURL

ECRのパスワードを取得

ローカルでecr get-loginを実行します。

$ aws ecr get-login
docker login -u AWS -p xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -e none https://xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com

こんな感じでずらーっと出てきますので、これの-pの引数がパスワードになるので、この値を控えます。

pipelinesの環境変数を設定

リポジトリの「設定」->「Environment variables」からpipelinesで利用する環境変数の設定ができます。 変数名を「ECR_PASSWORD」、値を控えたパスワードにします。ついでにSecuredにチェックを入れておくのが推奨です。

これでpipelinesを走らせればECRのイメージを使えます。

参考

ChatOpsとTerraformについて発表しました

それぞれの資料はこちら

両方ともこれから始める人むけの資料です。

ChatOpsもTerraformも、うまく使いこなせれば生産性や効率が格段に上がります。

それなのになかなか導入しているところが少ないのは、やっぱり会社の文化や業務の適不適はあるのかなーと気がしますが、そしてそこを押し通すのはすごい努力がいりますが、それ以外の「なんか怖い」「難しそう」などなど技術的な障壁がある人に本資料が役立てれば、嬉しいなーと思います。

とはいえ自分もまだまだ完璧に使いこなせているかといえばそうでもないので、日々勉強中です。

また知見が溜まったらどこかで発表したいですね。

CircleCIでAndroidのビルドが失敗する

いつも通りにビルドしたら以下のメッセージがでた。

Could not find com.android.support:appcompat-v7:22.2.1.

Androidのsupportライブラリがみつからないとか。

対処

明示的にライブラリをアップデートするように指定

  • 変更前
dependencies:
  override:
    - echo y | android update sdk --no-ui --all --filter "android-22,build-tools-21.1.2"
  • 変更後
dependencies:
  override:
    - echo y | android update sdk --no-ui --all --filter "android-22,build-tools-21.1.2,extra-android-m2repository,extra-android-support"

Terraformで最低限のAWS環境を作ってみた

タイトル通り。

Terraformってなに?

インフラの構成をコード化するもの。

AWSに限っていうと、VPCやSecurityGroup、GatewayからEC2などなどをコード化できる。 (Terraform自体はAWSだけでなく、DigitalOceanやHerokuなど各種サービスに対応している)

サーバの中身をコード化するChefやAnsibleなどとはそもそも異なる。

Terraform by HashiCorp

インストール

Macの場合はHomebrewで一発

% brew install terraform

2015/07時点の最新版である0.6がインストールされた。 以降、0.6でのお話し。

設定

tfファイルで構成を定義する。 以下、AWSインスタンスを作成する設定サンプル。

# Credential
provider "aws" {
    access_key = "xxxxxxxxxx"
    secret_key = "xxxxxxxxxx"
    region = "ap-northeast-1"
}

# Create instance
resource "aws_instance" "sample" {
    ami = "ami-cbf90ecb" # Amazon Linux AMI 2015.03 (HVM), SSD Volume Type
    instance_type = "t2.micro"
    tags {
      Name = "sample"
    }
}

コマンド

作成したtfファイルを元に適用のテストをする(ようはdry-run)

% terraform plan

作成したtfファイルを元に構成を適用する

% terraform apply

構成を全て破棄する

% terraform destroy

構成を確認する

% terraform show

試しに

AWSで一通りの構成を作ってみた。

github.com

これで作れるものは以下。

  • Key Pairs
  • VPC
  • Subnets
  • Internet Gateway
  • Route Tables
  • Security Groups
  • EC2
  • ELB

気になったこと

tfstateファイルについて

terraform applyを実行すると、tfstateファイルが作成されます。

こいつが現在の生の構成を把握するファイルみたいなので、複数人で利用する場合は統一する必要があります。

インスタンスの設定変更について

EC2インスタンスを一度立ち上げた後に設定を変更する場合、なんと一度Destroyしてからの再作成となります。 SecurityGroupを追加してもそうなりました(ただ、タグの追加は大丈夫でした) 完璧にImmutable化できているのなら大丈夫ですが、そうでない場合やインスタンスの用途がDB系である場合は要注意かと思います。

感想

使ってて気持ちいい。 apply -> destroy -> applyして全く同じ環境ができるのはちょっと感動。 初めて構成管理ツール使った時の感覚を思い出しました。

とりあえずは軽めのところから実践投入する予定。