terraformでASGを作る時の注意点

概要

起動設定を更新した際に相関関係にあるASGで起動しているインスタンスが作り直されてしまうので、これを回避する。

方法

EC2Resourcesaws_launch_configurationを使用時、引数にnameではなく name_prefixを使用する。

launch_configuration.tf
resource "aws_launch_configuration" xxxxxxxx-autoscaling-conf" {
  name_prefix                 = "xxxxxxxx-autoscaling"
  image_id                    = "ami-xxxxx"
  instance_type               = "t2.medium"
  iam_instance_profile        = "xxxxxxxx"
  key_name                    = "xxxxxxxx"
  security_groups             = ["sg-xxxxxxxx"]
  associate_public_ip_address = true
  user_data                   = "${file("xxxxxxxx.sh")}"
  root_block_device  {
    volume_type           = "gp2"
    volume_size           = "50"
    delete_on_termination = "true"
  }
  lifecycle  {
    create_before_destroy = true
  }
}
  • IDのみがユニークなものに置換され、ASGは影響を受けない
aws_launch_configuration.xxxxxxxx-autoscaling-autoscaling-conf:
  id = xxxxxxxx-autoscalingxxxxxxxxxxxxxxxx

続きを読む

Terraform v0.10.0 で tfstate を Amazon S3 に保存する

tfstate は git に登録すべきではないものなので、 Amazon S3 に保存するのが楽っぽい。
これには AWS のアクセスキーが必要だけど、これも当然 git で管理するわけにはいかない。
このあたりは先人がいろいろ試行錯誤してまとめられている。

なんだけども Terraform v0.9 以降と v0.8 以前ではやり方が結構違うらしく、日本語の記事は
v0.8 以前からの移行方法がほとんどであまり参考にならない。
しかも v0.10 は 8/3 にリリースされた直後なのでほぼ情報はない。
なんとか判明したのは、 backend という仕組みが導入されて S3 はその1種となったこと。

いろいろ試行錯誤した結果、なんとか安全に管理できるようになったのでまとめてみる。

前提

  • Windows 10 x64
  • AWSCLI v1.11.129
  • Terraform v0.10.0

1. bucket 作成

Amazon S3 に tfstate を保存するので、あらかじめ bucket を作成しておく。
バージョニングを有効にするのが推奨らしい。

2. profile 作成

AWSCLI でアクセスキーなどを保存する profile を作成する。
アクセスキーはあらかじめ作成してテキストファイルなどに保存しておく。

aws configure --profile your_profile_name
> AWS Access Key ID [None]: your_access_key
> AWS Secret Access Key [None]: your_secret_key
> Default region name [None]: ap-northeast-1
> Default output format [None]:

この結果は %HOME%.aws に保存される。

3. tf ファイル作成

Terraform で AWS を使う場合、 provider にアクセスキーを指定する記事が多いが、
tfstate を S3 に保存するには backend にもアクセスキーを指定する必要がある。
しかし、 provider と違い backend には tf ファイルでアクセスキーを指定できない。

ただし backend には profile を指定できるので、 provider にも profile を指定すると
アクセスキーを同じように管理できていい感じ。
具体的には tf ファイルを次のように記述すればよい。

main.tf
terraform {
  required_version = ">= 0.10.0"

  backend "s3" {
    bucket  = "your_bucket_name"
    key     = "path_to_tfstate"
    profile = "your_profile_name"
    region  = "ap-northeast-1"
  }
}

provider "aws" {
  profile = "your_profile_name"
  region  = "ap-northeast-1"
}```

続きを読む

terraform destroy で IAM Policy を削除するときは予めデタッチ

※ 対象Ver: Terraform v0.8.8
 v0.9 以降は未確認。

TerraformでアタッチしたものであればDestroy処理の中でデタッチされるが、そうでないもの(Terraform管理外のアタッチ)は予めデタッチしておかないとエラーになる。
初期構築時にTerraformでポリシーを作り、運用でTerraformを使わずにアタッチしていた環境で、このケースにハマった。

そのときのメッセージは以下。

aws_iam_policy.xxxxxxxx: Destroying...
Error applying plan:

1 error(s) occurred:

* aws_iam_policy.xxxxxxxx: Error reading IAM policy 
arn:aws:iam::xxxxxxxx:policy/xxxxxxxx: 
&awserr.requestError{awsError:(*awserr.baseError)(0xc42064a840), 
statusCode:409, requestID:"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}

Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.

エラーメッセージ内に Error reading IAM policy とあったのでTerraform実行IAMの権限の問題かと最初は考えたが、何度見直しても権限は足りている。
その場合、AccessDeny というメッセージが出るはずだし。

statusCode:409 で検索したら Conflict という言葉が出てきたので原因に気付くことができた。
わかりづらくないですか。

続きを読む

TerraformでAWSの構成を読み取るぞ(Terraform import)

前書き

Terraform import については、Qiitaでお2人も記載してくれていますので、参照ください。

tyasuさん:terraform importの使い方メモ
kt_higaさん:terraform importを試してみた

同じスタンスで記載してもしょうがないので、勉強している最中に違う観点でいくつかTerraform import について記載します。

環境

Windows にTerraform(2017/7/18時点:v0.9.11)をインストール
AWSには、EC2,ELB,RDS,S3 など以前手作業で作った環境があります。

準備

まずは、最低限Terraformの利用には、access_key, secret_keyが必要です。
こちらを参照してキーを確認しましょう。
Windowsの作業フォルダにファイルを作成して、確認したキーを記載します。
※ ファイル名は、<任意の名前>.tf としてください。
ここでは、c:work フォルダを作業フォルダとします。

provider "aws" {                                            ・・・・決め打ちです。
    region      = "ap-northeast-1"                          ・・・・リージョンを記載(ap-notheast-1:日本リージョン)
    access_key  = "XXXXXXXXXXXXXXXXX"                       ・・・・access_keyを登録
    secret_key  = "YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY" ・・・・secret_keyを登録
}

※ ほとんどが決め打ちです。
   今回は、AWS環境のため"aws" となります。

インポート!

叩くコマンドは、簡単!

AWSのマネジメントコンソールから、インスタンスID(赤枠部分)を確認して、コマンドのオプションに指定します。
C:> cd work
C:work> terraform import aws_instance.<任意の名前> <インスタンスID>

題.png

ここでは、こんな感じでコマンドを叩いてみました。
もともとの環境では、タグ名を「batchserver01」という名前を付けていましたが、ここではわざと「batch01」に変更しています。
タグ名と合わせても勿論OKです。

import02.png

無事、terraform.tfstate ファイルが作成されました。

※ <> 部分は、修正しています。

{
    "version": 3,
    "terraform_version": "0.9.11",
    "serial": 0,
    "lineage": "XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
    "modules": [
        {
            "path": [
                "root"
            ],
            "outputs": {},
            "resources": {
                "aws_instance.batch01": {
                    "type": "aws_instance",
                    "depends_on": [],
                    "primary": {
                        "id": "<INSTANCE_ID>",
                        "attributes": {
                            "ami": "<AMI_ID>",
                            "associate_public_ip_address": "false",
                            "availability_zone": "<AvailabilityZone_ID>",
                            "disable_api_termination": "false",
                            "ebs_block_device.#": "0",
                            "ebs_optimized": "false",
                            "ephemeral_block_device.#": "0",
                            "iam_instance_profile": "",
                            "id": "<INSTANCE ID>",
                            "instance_state": "running",
                            "instance_type": "<INSTANCE_TYPE>",
                            "ipv6_addresses.#": "0",
                            "key_name": "<KEY_NAME>",
                            "monitoring": "false",
                            "network_interface.#": "0",
                            "network_interface_id": "<NW_INTERFACE_ID>",
                            "primary_network_interface_id": "<NW_INTERFACE_ID>",
                            "private_dns": "<DNS_NAME>",
                            "private_ip": "<PRIVATE_IP>",
                            "public_dns": "",
                            "public_ip": "",
                            "root_block_device.#": "1",
                            "root_block_device.0.delete_on_termination": "false",
                            "root_block_device.0.iops": "100",
                            "root_block_device.0.volume_size": "10",
                            "root_block_device.0.volume_type": "gp2",
                            "security_groups.#": "0",
                            "source_dest_check": "true",
                            "subnet_id": "<SUBNET_ID>",
                            "tags.%": "1",
                            "tags.Name": "batchserver01",
                            "tenancy": "default",
                            "volume_tags.%": "0",
                            "vpc_security_group_ids.#": "1",
                            "vpc_security_group_ids.2148762998": "<SECURITY_GROUP_ID>"
                        },
                        "meta": {
                            "schema_version": "1"
                        },
                        "tainted": false
                    },
                    "deposed": [],
                    "provider": "aws"
                }
            },
            "depends_on": []
        }
    ]
}

ここから本題

★ EC2を1台しかimportしていないので、もう1台importしたらどうなるんだ?

import01.png

別に問題なくコマンド終了。
先ほど作成されたterraform.tfstate は、terraform.tfstate.backup にCOPYされ、terraform.tfstate に2台目が追記されました。
(省略)

★ S3をimport しても大丈夫だよね?

C:work> terraform import aws_s3_bucket.<任意の名前> <バケット名>

わざとバケット名を間違えて見ました。

import03.png

★ ALBをimport !!

C:work> terraform import aws_alb.<任意の名前> <ARN>

import04.png

結果、terraform.tfstate ファイルにはどんどんimport すればしただけ、追記されていきました。
どんどん下に追記されていくわけではなく、DataSource(aws_s3_bucket, aws_instance, aws_albなど)の名前で順に並んでいくようです。

参考サイト

対応しているDataSource をはじめ、オプション確認にはやっぱりここは外せません。

本家HashiCorp:AWS Provider

続きを読む

CloudFormationとTerraformの使用感〜2017年7月版〜

1.背景

2016年9月、CloudFormation(以下、CFn)がYAML書式に対応しました。
AWS CloudFormation の更新 – YAML、クロススタック参照、簡略化された置換

また、Terraformも0.9になったことで、各環境ごとに設定を切り替えることができるようになりました。
Terraform 0.9がリリース。0.8.xから0.9.xのStateマイグレーション手順をまとめました。
Summary of Terraform v0.9

これらのリリースによって、それぞれのツールに対する使用感が大分変わったので、
備忘がてら2017年7月時点でのCFnとTerraformの使用感をメモしておきます。
なお、本記事のTerraformは無料版なので、エンタープライズ版の使用感とは異なると思います。

2.TL;DR

AWSだけの運用に絞れる環境であれば、今はTerraformで環境ごとの設計を色々考えるよりも、
CFnで構築した方が運用する上でも大分楽なんじゃないかなーというのが執筆時点での感想です。

3.機能比較

主機能の違いは以下の通り。

機能 CFn CFn(2017/07時点) Terraform(~0.8) Terraform(0.9~)
書式 JSON JSON,YAML HCL HCL
対応環境 AWS AWS AWS,GCP,Azure,github,etc… AWS,GCP,Azure,github,etc…
実行管理 AWS AWS tfstate(JSON) tfstate(JSON)
実行権限 AccessKey AccessKey, IAM Role AccessKey AccessKey
環境分割方法 スタック分割 スタック分割、クロススタック参照 ディレクトリ分割、module&output機能 env分割、module&output機能

HCL:HashiCorp Configuration Language

この中で、各項目についての使用感を以下の項目で記載します。

3-1.書式の変遷

CFnの場合

兎にも角にも、CFnのYAML対応がとても嬉しいです。
JSONでもコメント文を書けるよという話はちらほらあったけど、少なくともパラメータやリソースそれぞれに対して、
下記のようにコメント文が記載できるようになっただけでも、大分視認性が上がるかなと。

CFnのYAML書式例

AWSTemplateFormatVersion: 2010-09-09
######################################
# Parameters Settings
######################################
Parameters:
  AppName:
    Type: String
    Default: hogehoge
    Description: App Name
(snip)
######################################
# Mappings Settings
######################################
Mappings:
  StackConfig:
    VPC:
      CIDR: 10.0.0.0/16
(snip)
######################################
# Resources Settings
######################################
Resources:
    VPC:
        Type: 'AWS::EC2::VPC'
        Properties:
            CidrBlock: !FindInMap [ StackConfig, VPC, CIDR ]
            EnableDnsSupport: true
            EnableDnsHostnames: true
            InstanceTenancy: default
(snip)
######################################
# Outputs Settings
######################################
Outputs:
  VPC:
    Value: !Ref VPC
    Export:
      Name: VPCId
(snip)

Terraformの場合

Terraformのドキュメントがかなりわかりやすいので、基本はここに記載されているresourceの使い方を学んでいくスタイル。
terraform planterraform applyの2種類のコマンドを使い、おおむね3日程度でTerraformで必要な書式方法がわかるかなと。

Terraformの書式例

#####################################
# VPC Settings
#####################################
resource "aws_vpc" "vpc_main" {
    cidr_block = "10.0.0.0/16"
    enable_dns_hostnames = true
    tags {
        Name = "${module.common.app_name}"
        Env = "common"
    }
}

######################################
## Internet Gateway Settings
######################################
resource "aws_internet_gateway" "vpc_main-igw" {
    vpc_id = "${aws_vpc.vpc_main.id}"
    tags {
        Name = "${module.common.app_name} igw"
        Env = "common"
    }
}

3-2.対応プラットフォームの変遷

CFnの場合

当然ながら、CFnはAWSの一種なので、AWS関連の操作に限られます。

Terraformの場合

Terraformは複数のプラットフォームを操作することが可能なので、マルチクラウド環境を運用するときにTerraform内のドキュメントを追えば、
必須のパラメータなりを見て、多少なりとも他環境でもキャッチアップしやすくなるかなと。
個人的には、TerraformでAWSのようなインフラ環境を操作するだけでなく、
以下のようにgithubのTeam設定もコード化しておいて、退職者対応とかでも履歴を残せるのがよいなと思います。

Terraformのgithubプロバイダ利用例

###########################
# Team Setting
###########################
resource "github_team" "hoge" {
  name        = "developer"
  description = "hoge"
  privacy     = "closed"
}

###########################
# Team Membership Setting
###########################
resource "github_team_membership" "maintainer" {
  team_id  = "${github_team.hoge.id}"
  username = "CkReal"
  role     = "maintainer"
}
resource "github_team_membership" "fuga" {
  team_id  = "${github_team.hoge.id}"
  username = "fuga"
  role     = "member"
}
(snip)
###########################
# Team Repository Setting
###########################
resource "github_team_repository" "hoge_test" {
  team_id    = "${github_team.hoge.id}"
  repository = "test"
  permission = "push"
}

3-3.実行管理の変遷

ここに対する認識が、両者の実運用方法において、大きく見解が別れるところだと思います。

CFnの場合

CFnは実行した結果がManagementConsoleで確認でき、CFnが管理しているリソースが可視化されています。

CFnの実行結果例

CFn_ManagementConsole.png

CFnの管理リソース例

リソース.png

Terraformの場合

Terraformの場合、terraform state listterraform showというコマンドや、terraform showコマンドとgraphvizを組み合わせたりして、管理しているリソースを確認できます。
ただ、基本的にtfstateファイルでリソース管理されているため、
CFnのような可視化を行いたいのであれば、ユーザー側で何かしらのツールなどを作成する必要があります。

terraform showコマンド実行例

% terraform show
github_team.administrator:
  id = XXXXXXX
  description = 管理者
  name = administrator
  privacy = closed
github_team.developer:
  id = XXXXXXX
  description = 開発者
  name = developer
  privacy = closed
github_team.operator:
  id = XXXXXXX
  description = 運用者
  name = operator
  privacy = closed

3-4.実行権限の変遷

CFnの場合

IAM Userの権限とは別に、実行するIAM Roleを選択できるようになっているので、必要なRoleをIAM Userに使用させるといったことが可能。

Terraformの場合

複数人でTerraformを利用するのであれば、TerraformのBackendにS3やGCSを利用したりして、同時実行を避けるような仕組みが運用上必須かなと思います。
そのため、このtfstateファイルを保存するS3のバケットポリシー設定や、そのS3を操作するIAM権限も考えておく必要があります。
(他で利用しているIAM Userがterraformで管理しているバケットを更新しないように設定するなど)

3-5.環境分割方法の変遷

CFnの場合

Parameterを活用すれば、どのSecurityGroupを変数で実行するかがプルダウンで指定できたりするのが便利です。このあたりは、流石にAWSのサービスだなあと感じます。
また、2016年にはクロススタック参照ができるようになったので、Stackの粒度を小さく管理できるようになり、共通変数を使いまわししやすくなりました。

Terraformの場合

0.8以前は、moduleとoutputを使用して、ディレクトリごとtfstateを分割し、必要な環境変数はgetコマンドで取りに行く方針が主流だったと思います。
0.9になると、ここにenvの概念が出てきて、同じディレクトリ内で環境を切り替えるといったことができるようになり、backendに設定したtfstateも分割することができるようになりました。

4.まとめ

CFnもTerraformもどんどん機能追加されて、進化していっています。
Terraformについては、私が使い始めた頃はplanapplyのみを中心に考えていけばよかったのですが、0.9以降になるとenvgetの概念も使いこなす必要が出てきました。
また、さらにbackendにS3を使うなら、S3やIAMの権限設計といった感じで、Terraformを安全に使うために考えることが多くなってきた感じです。
CFnについては、JSONのみで別Stackへ変数を渡せなかったりした時代から、
YAML対応,クラススタック参照,変更セットといった機能が追加され、かなりAWS環境の実運用で回せるように洗練されてきた印象です。

続きを読む

terraformでS3バケットのACLに権限を付与する

CloudFrontのアクセスログをS3に保存させる事はごくごく普通にあると思いますが、terraformで環境を構築しているとS3作成時に特殊なACLは設定できず、CloudFront作成時にログ出力指定をしていると権限不足で落ちてしまいます。

参考: アクセスログ – Amazon CloudFront

terraformだけで解決できれば一番良いのですが、2017年6月現在ではissueが出ているものの反映されるのはまだ先になりそうな感じです。

GUIからぽちぽちしてると勝手にACLを作ってくれるので、手で作った後にterraformに記載するとかいう意味のない作業をしていたのですが、そんな作業やりたくなかったので無理やり気味ではありますがterraform applyを実行するだけでS3にACLを付与し、CloudFrontの構築まで一気通貫で行えるようにちょっとした工夫を加えてみました。

準備するもの

linux/mac前提です。windowsの場合はbash on windowsであれば動作可能です。

必須

  • terraform
  • AWS CLI

推奨

  • direnv

準備するスクリプト

bin/AssignAwsdatafeedsAcl
#!/bin/sh

# 自身のディレクトリパスを取得
CURRENT_DIR=$(cd $(dirname $0);pwd)/

# 引数のチェックを行う
if [ $# -ne 1 ]; then
    exit 1
fi

# バケット名を引数から取得
BUCKET_NAME=$1

TEMP_FILE=$(mktemp)

# S3待ち(waitが無い場合にエラーが発生)
sleep 2

# 現在のバケットACL情報を取得する
aws s3api get-bucket-acl --bucket ${BUCKET_NAME} > ${TEMP_FILE}
if [ $? -ne 0 ]; then
    # テンポラリファイルを削除する
    rm -f ${TEMP_FILE}
    exit 1
fi

# ACLにawsdatafeeds権限が含まれていない場合は追加する
grep awsdatafeeds ${TEMP_FILE}
if [ $? -eq 1 ]; then
    # 追記する文字列を取得
    INPUT_LINES=$(perl -p -e 's/n/\n/' ${CURRENT_DIR}acl.txt)
    if [ $? -ne 0 ]; then
        # テンポラリファイルを削除する
        rm -f ${TEMP_FILE}
        exit 1
    fi

    # 権限情報を追記
    sed -i -e "s/("Grants": *[)/1n${INPUT_LINES}/" ${TEMP_FILE}
    if [ $? -ne 0 ]; then
        # テンポラリファイルを削除する
        rm -f ${TEMP_FILE}
        exit 1
    fi

    # 権限情報をS3バケットに反映
    aws s3api put-bucket-acl --bucket ${BUCKET_NAME} --access-control-policy "$(cat ${TEMP_FILE})"
    if [ $? -ne 0 ]; then
        # テンポラリファイルを削除する
        rm -f ${TEMP_FILE}
        exit 1
    fi
fi

# テンポラリファイルを削除する
rm -f ${TEMP_FILE}

exit 0
bin/acl.txt
        {
            "Permission": "FULL_CONTROL",
            "Grantee": {
                "DisplayName": "awsdatafeeds",
                "ID": "c4c1ede66af53448b93c283ce9448c4ba468c9432aa01d700d3878632f77d2d0",
                "Type": "CanonicalUser"
            }
        },

上記2ファイルをパスが通ったところに配置しておきます。
シェルスクリプトの方にはちゃんと実行権限を付与しましょう。

ちなみにdirenvを使って、terraform実行パスなどでPATHを追加するのが推奨です。

.envrc
export AWS_DEFAULT_PROFILE=[AWSプロファイル名]
export AWS_DEFAULT_REGION=[デフォルトとするリージョン]

export AWS_PROFILE=$AWS_DEFAULT_PROFILE
export AWS_REGION=$AWS_DEFAULT_REGION

PATH_add `pwd`/bin

terraformの記述

s3.tf
resource "aws_s3_bucket" "sample" {
    bucket = "sample-cfn-logs"
    acl    = "private"
    tags {
         Name = "sample-cfn-logs"
    }

    provisioner "local-exec" {
         command = "AssignAwsdatafeedsAcl ${aws_s3_bucket.test.bucket}"
    }
}

概要

terraformのprovisionerにlocal-execという、実行マシンでのコマンド実行機能があります。

これはリソースが作成されたのちに実行されるので、S3リソースが作成された後にシェルスクリプトを実行し、AWS CLIを利用してS3バケットにACLを付与しています。

上記スクリプトでは下記の様な処理を行っています。

  1. aws cli: S3バケットの設定済みACLを取得
  2. shell: 取得したACLにawsdatafeedsの権限が付与されているかチェックする
  3. shell: 権限がない場合、権限の内容を取得したACLに追記する
  4. aws cli: 改変したACL情報をS3バケットに反映する

S3バケットが構築されてからAPIで叩けるまでに微妙なタイムラグがあるらしく、sleepが入っていないとAPIを叩いた時にバケットが存在しないと怒られてしまいます。

ちゃんとするならば、APIのレスポンスを見て待つ処理を入れるのが良いのですが、terraformがMulti ACLに対応するまでの暫定的な対応なのでsleepで濁しています。

配置したスクリプトにパスが通っていないとlocal-execの指定時にわざわざパスを書いてあげる必要があるので、direnv使ってパス通しちゃいましょう。

相対パスがどこからになるのか知らない。

ちなみにacl.txtの内容を変えると好きな権限を入れれます。でもあまり使わないですし変更検知もされないので推奨はしません。

どうしてもという場合はaws_s3_bucketリソースの代わりにnull_resourceリソースを使って毎回スクリプトをキックするようにした上で、前回実行のACLと反映するACLに差分がある時に実行するなど工夫をしてみてください。

結論

はよterraform自体で対応して。

続きを読む

Terraformを利用して、AWS EC2を作成してみた

概要

Terraformを利用してAWSのEC2を作成してみました。
terraformを実行するのはIAM Roleで権限を付与したインスタンスからになります。

ドキュメントを見るといろいろと出来そうですね。
https://www.terraform.io/docs/

コードは下記になります。
同じ階層のディレクトリに変数の設定を入れてあげてください。

ec2_dev.tf

provider "aws" {
  region = "${var.region}"
}

resource "aws_instance" "dev" {
    ami = "${var.ami_id}"
    instance_type = "${var.instance_type}"
    key_name = "${var.key_name}"
    iam_instance_profile = "${var.iam_role}"
    vpc_security_group_ids = [
        "${var.sg_id}"
    ]
    subnet_id = "${var.subnet_id}"
    associate_public_ip_address = "true"
    root_block_device {
        volume_type = "gp2"
        volume_size = "8"
        delete_on_termination = "true"
    }
    tags {
        Name = "${var.tag_name}"
        env = "${var.tag_env}"
    }
}

https://github.com/handa3/study/blob/master/terraform/ec2/ec2_dev.tf

続きを読む

tectonic で kubernetes クラスタを構築・管理する(AWS)

概要

tectonic で AWS に kubernetes クラスタを構築する。

対応プラットフォーム(2017.06.09 時点)
  • AWS
  • Bare Metal
  • Microsoft Azure (alpha)
  • OpenStack (pre-alpha)
料金
  • 10ノードまで無料

環境

インストーラを実行した環境
– Amazon Linux AMI 2017.03
– tectonic 1.6.4

事前準備

セットアップ前に必要な作業

  • CoreOS

    • CoreOS アカウントサインアップ
    • CoreOS License 取得 (tectonic-license.txt)
    • Secret 取得 (config.json)
  • AWS

    • IAM Role 設定 (Policy)
    • Route 53 でパブリックホストゾーンの作成

tectonic のインストーラー取得

ダウンロード・解凍

$ wget https://releases.tectonic.com/tectonic-1.6.4-tectonic.1.tar.gz
$ tar xzvf tectonic-1.6.4-tectonic.1.tar.gz
$ cd tectonic

tectonic セットアップ (GUI)

インストーラー起動

$ ./tectonic-installer/linux/installer -address=0.0.0.0:4444 -open-browser=false
Starting Tectonic Installer on 0.0.0.0:4444

ブラウザで インストーラーを起動したホストIPアドレス:4444 にアクセスして、画面に従いセットアップする

01.png

tectonic セットアップ (terraform)

インストーラーの環境設定

$ export INSTALLER_PATH=$(pwd)/tectonic-installer/linux/installer
$ export PATH=$PATH:$(pwd)/tectonic-installer/linux

terraform 環境設定

$ sed "s|<PATH_TO_INSTALLER>|$INSTALLER_PATH|g" terraformrc.example > .terraformrc
$ export TERRAFORM_CONFIG=$(pwd)/.terraformrc

cluster resources 取得

$ terraform get platforms/aws

credential を環境変数に設定

$ export AWS_ACCESS_KEY_ID=AK***************
$ export AWS_SECRET_ACCESS_KEY=**************************************
$ export AWS_REGION=ap-northeast-1

クラスタ設定

クラスタ名を設定

$ export CLUSTER=cluster-1

クラスタ環境設定

$ mkdir -p build/${CLUSTER}
$ cp examples/terraform.tfvars.aws build/${CLUSTER}/terraform.tfvars

terraform 環境設定

$ vi build/cluster-1/terraform.tfvars

設定内容

tectonic_admin_email = "********************"   #tectonic console ログインID
tectonic_admin_password_hash = "*************"  #ログインパスワード※

tectonic_aws_az_count = "1"
tectonic_aws_region = "ap-northeast-1"
tectonic_aws_ssh_key = "************"           #AWS に登録した Key pair

tectonic_base_domain = "*************"          #Route 53 に登録したドメイン
tectonic_cluster_name = "cluster-1"             #クラスタ名

tectonic_license_path = "/path/to/tectonic-license.txt" #事前に取得した CoreOS Lisence
tectonic_pull_secret_path = "/path/to/config.json"      #事前に取得した CoreOS Secret

tectonic_worker_count = "2"                     #worker ノード数

tectonic_admin_password_hash は bcrypt で hash 化する (bcrypt-hash tool)

$ wget https://github.com/coreos/bcrypt-tool/releases/download/v1.0.0/bcrypt-tool-v1.0.0-linux-amd64.tar.gz
$ tar zxvf bcrypt-tool-v1.0.0-linux-amd64.tar.gz
$ ./bcrypt-tool/bcrypt-tool 
Enter password: 
Re-enter password: 
$2a$10$*****************************************************

plan 実行

$ terraform plan -var-file=build/${CLUSTER}/terraform.tfvars platforms/aws
Plan: 116 to add, 0 to change, 0 to destroy.

クラスタをデプロイ

apply 実行

$ terraform apply -var-file=build/${CLUSTER}/terraform.tfvars platforms/aws

クラスタへのアクセス

作成された kubeconfig を読み込み

$ export KUBECONFIG=generated/auth/kubeconfig

クラスタ確認

$ kubectl cluster-info
Kubernetes master is running at https://cluster-1-api.***.****.jp:443
KubeDNS is running at https://cluster-1-api.***.****.jp:443/api/v1/proxy/namespaces/kube-system/services/kube-dns

ノード確認

$ kubectl get node
NAME                                             STATUS    AGE       VERSION
ip-10-0-22-59.ap-northeast-1.compute.internal    Ready     4m        v1.6.4+coreos.0
ip-10-0-37-60.ap-northeast-1.compute.internal    Ready     2m        v1.6.4+coreos.0
ip-10-0-52-127.ap-northeast-1.compute.internal   Ready     1m        v1.6.4+coreos.0

tectonic console にアクセス

ブラウザで https://{{ tectoniccluster_name }}.{{ tectonic_base_domain }}/ にアクセス

12.png

設定したログインID、パスワードでログインする

13.png

続きを読む